Re: [AD] fixes for some al_resize_display cases in Windows

[Dennis-Busch@xxxxxxxxxx]

On 14 Jul 2012 at 15:59, Elias Pschernig wrote:
> On Fri, 13 Jul 2012 23:27:23 +0200
> Dennis-Busch@xxxxxxxxxx wrote:
> 
> Hm. The code is broken right now. And works with your patch. I'm still
> not comfortable applying it since I don't understand what it does at
> all. So it's probably best if Trent looks over it first. Else I'll at
> least wait until I find time to boot into Windows and re-produce all
> the issues.

Yes, it's best if he or someone who knows the driver internals better
double checks the fixes to see if they don't break anything else.
I have tested it with the examples and the test runners and did not
find any issues though but that does not mean there are none of
course.

> Maybe you can also explain what your changes do below?
> 
> > New patch is attached (also fixes OpenGL bitmap preservation between
> > fullscreen mode changes now:
> > https://sourceforge.net/tracker/?func=detail&aid=3543463&group_id=56
> > 65&atid=105665 ).
> > 
> > Patch notes:
> > * fixed missing/incorrect resize events under Windows   in
> >  Direct3D and OpenGL displays (could be seen in
> >  ex_display_events)
> > 
> 
> Which part of the patch does that?

That's the part where the ignore resize flags were not set to false 
again. And the OpenGL driver was not acknowleding the resize the
same way the D3D one did.
see d3d_resize_display (in d3d_disp.c)
and wgl_resize_display (in wgl_disp.c)
 
> > * fixed a case where changing fullscreen mode in D3D via
> > al_resize_display caused a crash and loss of loaded bitmaps
> > information causing the bitmap not to be converted and thus
> > disappearing after mode change (problem could be observed running
> > ex_fs_resize)
> 
> Same.

The D3D driver tried to use the same refresh rate as for the previous
fullscreen mode on al_resize_display. This failed on my CRT monitor 
because it did not support that refresh rate. 

(This is why I re-initialize the refresh-rate to 0 in the resize code
branch for fullscreen resize in D3D.)

As a result the display failed to find a matching mode and was 
destroyed in d3d_display_thread_proc which caused the loss of the
bitmaps attached to that display.

Then after the thread fails and ends, execution continues in 
d3d_create_display_internals
where it tried to create a fresh display template (according to a
comment there) which was using garbage memory values for width and 
height (I fixed that with pre_destroy_w, pre_destroy_h which are 
grabbed before the display is destroyed).

> > * fixed a case where changing fullscreen mode in OpenGL(Windows) via
> >   al_resize_display cause nothing at all to be rendered after the
> > mode change
> 
> What was the problem, and how does the patch fix it?

The problem was a combination of multiple hard to find issues.
One was what I stated above (OpenGL driver was not acknowleding the 
resize at all).
Another one was that the ModelView matrix was not initialized after
resize (containing all zeroes (this is what we debugged via
debugger screenshots in #allegro)).

> > * fixed OpenGL(Windows) bitmap preservation between fullscreen mode
> > changes (problem could be observed running ex_fs_resize with an
> > OpenGL display) (major credits to Elias who helped debugging this
> > through screenshots of debugger states and by providing tons of
> > knowledge)
> > 
> 
> Is it ok to call _al_opengl_backup_dirty_bitmaps in every
> al_flip_display? It seems to be what IOS does as well so probably no
> performance problem.
 
> But a comment about it would be nice. Stating that this is not
> necessary (since WGL can *never* lose a texture) - but just simplifies
> code elsewhere to have the bitmap synched to memory.

Without the _al_opengl_backup_dirty_bitmaps, the memory pointers did 
not contain the correct data which caused preservation of bitmaps to 
memory bitmap in destroy_display_internals in wgl_disp.c to fail and
thus bitmaps could also not be reconverted to video after the mode
change.
 
> Also, at one point you just set the refresh rate to 0. Will it still
> honor the refresh rate possibly requested by the user?

I think it should actually not honor the refresh rate the user
requested initially when created the display first because when the
user requests a true fullscreen re-size, the new mode may not support 
that old rate (and just that was the case which caused a crash here).

The initial refresh rate for the first fullscreen mode set is honored
because the reset to 0 is only made inside d3d_resize_helper.

---
All in all, I debugged this for way too many hours to remember all 
the details though. I tried to describe what I remember as best as 
possible above.

Let me know if anything still needs further explaining.

Dennis Busch
d_busch@xxxxxxxxxx