First of all after 4 hours of debugging I have no problem with my code. But I'm curious why I had issue that I had.
I created fullscreen window with d3d11 rendering. Problem occurred when I tried to alt-tab window and didn't have Present() in my loop (I simply found this issue before implementing rendering function). In that case after minimizing window Red and Blue channels on my screen were swapped (yes, literally).
It took me long time to find because I suspected my swap chain or window itself (sdl). Can you help me find the reason of this bug- for educational purposes?
This usually is due to a graphics driver bug with RGBA swap chains. You can try updating your driver (run Windows Update). But to improve compatibility you can change your swap chain surface format to BGRA (specifically, B8G8R8A8_UNORM). As long as you are just doing normal rendering (and not doing anything fancy like UpdateSubresource directly to the back buffer), you should be able to leave everything else as-is and it will render correctly.
Related
I have for a very long time experienced a hugely annoying problem with the TStatusBar VCL control, a thin wrapper around the Win32 status bar control.
Since this appears to me as a very common and frustrating issue, I am very surprised Google (and StackOverflow) doesn't seem to know much about it.
The problem is that the status bar text becomes very blurred when it hasn't changed for a while; the precise conditions are still unknown to me. But I see this every day:
If one of the panels has its text updated, the new text is rendered correctly (see last panel):
Is this something that only happens when I am in the vicinity of running Delphi processes, or is it indeed a known issue? More importantly, is there a known cure? (And, academically, why does this happen? It wouldn't surprise me if it is related to transparent drawing of anti-aliased text by code originally designed for unthemed Win9x.)
I have tried to enable double-buffering, but I am not sure if that completely resolves the issue. (I have seen even worse behaviour in non-double-buffered list view controls, which is resolved by making them double-buffered.)
I made all status bars in my applications double-buffered a week ago, and I haven't seen any blurred text in any of them since then. Previously, I saw severely blurred text daily. Hence, it seems like this issue - whatever is causing it - can be fixed by making the status bars double buffered.
I just hit something particularly hard to debug when doing some pretty intensive rendering with Canvas2D. I use all kinds of things, from globalCompositeOperation to multiple off-screen canvases, with some drawImage magic in-between.
It works perfectly fine and smooth on :
Chrome (26) [OSX 10.7.5]
Safari (6.0.2) [OSX 10.7.5]
Firefox (Both 18 and 20 Aurora) [OSX 10.7.5]
Chrome (24) [Windows 7]
Firefox (12) [Windows 7]
Chromium (24) [Archlinux, Gnome 3]
EDIT: Added tests for Windows 7. Strangely enough, it works for FF12 (I had an old version on my dual boot) but there's a definite performance hit after upgrading to FF18. It's not as bad on Windows as it is on Linux though, and the same version on OSX works flawlessly. Regression maybe?
For some reason, on Firefox and Linux (I tried both 18 and 20 Aurora), I have bad rendering performances when dragging and rendering at the same time.
If I fire-and-forget an animation, it is on par with Chrome/Safari, but if I drag and render, I often end up only seeing the end frame after I release the drag.
Neither requestAnimationFrame nor a direct rendering on the mouse event handler work.
After profiling, the reported timings for the rendering parts are well within the range of acceptable (up to 100ms at the absolute worst), and definitely do not correspond to what I see on the screen.
I tried reducing the load by removing some stuff, ending up with reported render times under 15ms, but what I saw didn't change.
What baffles me is that it works almost everywhere else except with Firefox on Linux. Any idea as to where I should look, a bug report or a solution to my problem?
I have fully switched to Chrome on linux because of this issue. It stems from the old 2d rendering engine they are using called Cairo, which is old and out-dated. Azure was to replace this engine and they have it done basically all the platforms except linux.
http://blog.mozilla.org/joe/2011/04/26/introducing-the-azure-project/
https://bugzilla.mozilla.org/show_bug.cgi?id=781731
I think I know where you should look based on this:
If I fire-and-forget an animation, it is on par with Chrome/Safari, but if I drag and render, I often end up only seeing the end frame after I release the drag.
This is probably a double-buffering bug with Firefox on linux.
Canvas implementations have double-buffering built in. You can see it in action on any browser in a simple example like this one: http://jsfiddle.net/simonsarris/XzAjv/ (which uses a setTimeout vs extra work to illustrate that clearing does not happen right away)
The implementations try to delay all rendering by rendering it to an internal bitmap, and then all at once (at the next pause) render it to the canvas. This stops the "flickering" effect when clearing a canvas before redrawing a scene, which is good.
But it seems there's a plain old bug in the Linux Firefox. During your drag and render it seems to not be updating the canvas, probably in an attempt to buffer, but seems to be doing so when it should not be. This would explain why it works in fire-and-forget scenarios.
So I think a bug report is in order. I haven't got any linux machines lying around so I can't reproduce it and submit something myself to be certain though, sorry.
This is in reply to a comment: You could, during the mouse move, dispatch the drawing portion to a tiny timer.
For instance:
// The old way
theCanvas.addEventListener('mousemove', function() {
// if we're dragging and are redrawing
drawingCode();
}, false);
// The new way
theCanvas.addEventListener('mousemove', function() {
// if we're dragging and are redrawing
// in 1 millisecond, fire off drawing code
setTimeout(function() { drawingCode(); }, 1);
}, false);
There isn't such a method, its totally hidden. What you could do is, during mouse move, dispatch
I'm now writing a game on WP7 using XNA Framework 4.0.
There are some pictures that needs to be tiled.
So I set the SamplerState[0] to LinearWrap before rendering these pictures and I switch it back to LinearClamp once done.
However, the game still throws exceptions when it has finished all the tiled pictures and is about to create a VertexBuffer for the first non-tiled (i.e. not wrapped) picture.
I've added a breakpoint at that line and has confirmed that GraphicsDevice's Samplerstates[0] is LinearClamp. All other 15 SamplerStates are LinearWrap but I'm not using any multi-texture features so I don't think it's the reason. (frankly, I don't even know how to use multi-texture in XNA, maybe DualTextureEffect?)
BTW, I've desperately set all 16 samplers to LinearClamp, but the problem still occurs.
Anyone has encountered similar problems or has any solution?
#Blau had it in his comment.
Simply select the images you're using, open the properties window, expand Content Processor, and switch "Resize to a power of two" to true.
I recently had a client contact me asking for an update to his project that I used to maintain/develop years ago.
It was done using Macromedia Director (now Adobe Director) and Lingo. Since I haven't developed anything using these technology in such a long time I need some assistance.
The majority of the changes are simple, but what has got me stumped is making the application be able to toggle between full-screen projector and windowed-mode.
This is how it is organised:
I have a stub projector, which is lightweight and ensures a quick start-time.
The stub projector loads the main movie. ("#::Content:Main")
This stub projector is published with in full-screen mode.
Now, I can create a projector that is windowed and one that is full-screen mode by publishing separate executables. However what the client wants is the ability to switch this at runtime - is this even possible?
I have found a few workarounds that kinda work (setting the display-rect and stage-rect to the desktop size) but introduce numerous compatibility issues.
Any advice? Solutions?
I am tempted to say that it isn't possible to switch at runtime and recommend that he publishes either a full-screen or a windowed version.
For future reference: http://www.directorforum.com/showthread.php?p=38795#post38795
Well there are different ways to
define "full screen", but all can be
done at runtime:
1) The projector automatically adjusts
the computer's display resolution to
match the dimensions of the movie and
hides the taskbar/dock. This is
generally what "full screen" means in
modern parlance. You can check out
various Xtras for switching the
resolution on the fly.
2) In Director terms, publishing a
projector 'full screen' just means
that the projector window has no
titlebar, takes up the full dimensions
of the display, hides the
taskbar/dock, and has the movie
content centered on screen framed by a
solid background color. This is a
pretty lame implementation of full
screen since it doesn't make the movie
appear any bigger onscreen. This can
be set at runtime by manipulating the
rects that you mention and using an
Xtra to hide the taskbar. Not sure
what "compatibility issues" you ran
into.
3) Graphically stretch the movie so
that its actual content takes up the
entire screen. The easiest way to do
this is by altering the drawRect. But
this can result in distorted graphics
depending on how much stretching is
occurring, since no antialiasing is
used to smooth the stretched pixels.
Pardon my frustration. I've asked about this in many places and I seriously don't think that there wouldn't be a way in Windows 7 SDK to accomplish this.
All I want, is to capture part of a 'child window' ( setParent() ) created by a parent. I used to do this with bitblt() but the catch is that the child window can be any type of application, and in my case has OpenGL running in a section of it. If I bitblt() that, then the OGL part comes blank, doesn't get written to the BMP.
DWM, particularly dwmRegisterThumbnail() doesn't allow thumbnail generation of child windows. So please give me a direction.
Thanks.
It's been a while since I did any of this, so my explanation might be a bit vague, but from what I remember, the Windows doesn't "see" the OpenGL rendered inside the window.
What Windows does is create the window at the specified size and then "hands it over" to OpenGL for rendering. This means that you can't get at the pixels as rendered from the Windows side of the code.
When we wanted to capture the 3D we had to re-render the screen to an off screen bitmap which was then saved (or printed).
Obviously a whole screen capture (Print Screen) works because it's reading the final pixels.
I suggest that you:
Forget the Thumbnail part of the task (in terms of capture).
Calculate where your window is.
Capture full screen.
Excise the area you are interested in (using data from step 2).
Rescale to the appropriate thumbnail size.
Sorry, its more work, but it should work, which is better than what you have right now.
This may help:
http://code.google.com/p/telekinesis/source/browse/trunk/Mac/Source/glgrab.c?r=140
http://www.codeproject.com/KB/dialog/screencap.aspx
Also Java's Robot class (http://java.sun.com/javase/6/docs/api/java/awt/Robot.html#createScreenCapture%28java.awt.Rectangle%29)
I don't have access to the source code of any child window that may be open including the one with OpenGL