| Re: [AD] [ alleg-Bugs-1441740 ] window <-> fullscreen switching sometimes failed |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Elias Pschernig wrote:
On Thu, 2006-03-02 at 06:20 -0800, SourceForge.net wrote:
Bugs item #1441740, was opened at 2006-03-02 15:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105665&aid=1441740&group_id=5665
Attached is a version of the patch which applies cleanly against SVN. I
used the last patch posted on this list
(allegro-4.2.0-fullscreen2.patch), I assume it's the same as in the bug
report. The merge problems in the original are only the changed
FREE/MALLOC stuff. (Oh, btw., what was MALLOC_ATOMIC again?)
I can confirm the patch fixes the original problem here, and this time
also AGL apps keep working without any async replies. (Of course, they
still suffer from the original problem, since AGL uses its own window
code.)
The main change is, _xwin.window now is just a sub-window of
_xwin.wm_window (a toplevel window, with titlebar, icon, ...) or
_xwin.fs_window (a toplevel fullscreen window). Hm, btw., what happens
with _xwin.wm_window while in fullscreen mode?
It gets unmapped and mapped again when needed again, it could even stay
unmodified. (it would become black, but knowone would see as it would be
covered by the fullscreen window).
The unmap is there however to also make the window go away when
set_gfx_mode(TEXT, ...) gets called.
This change allows to fix the original bug without needing to re-create
keyboard and mouse cursors (and for 4.3 possibly GLX context), and also
allowed to implement a fullscreen mode which just has a window in the
center (_xwin.window) and black border around (from _xwin.fs_window).
And there's also some other minor clean up of xwin.c.
I hope I did get that all right, at least :)
You did, what is also new is that it when requesting a non-exisiting
videomode with XF86VM compiled in it will pick the smallest larger then
requested res, thus keeping the black borders to a minimum. The old code
would fail if a non existing vidmode was requested.
And it also does the blackborder fullscreen without XF86VM, also without
XF86VM it will report the screen res as the only available res in list
resolutions thus allowing apps who query for available resolutions and
then set one fullscreen to work without XF86VM.
Which means that the attached patch also should be applied to actually
make fullscreen available without XF86VM.
So, looks like Hans did a great job here. Alone the bravery to hack on
xwin.c with its over 3000 lines :) Really time to split it up into 2 or
3 separate files I guess.. anyway, if nobody sees a problem or still
wants to look at it, I'd like to apply it.
Good to hear you like it, after many years of xmame hacking I didn't
find the code hard to deal with, now the bug / problem was tough the
code was fine. Although it would indeed be easier to navigate it if it
was split over some more files.
Besides 300 lines is small:
[hans@xxxxxxxxxx projects]$ cat `find xmame/src/unix/video-drivers -type f`
`find xmame/src/unix/blit -type f` | wc -l
56070
Regards,
Hans
--- allegro-4.2.0/src/x/xgfxdrv.c~ 2006-03-08 22:47:27.000000000 +0100
+++ allegro-4.2.0/src/x/xgfxdrv.c 2006-03-08 22:47:27.000000000 +0100
@@ -61,7 +61,6 @@
-#ifdef ALLEGRO_XWINDOWS_WITH_XF86VIDMODE
static BITMAP *_xwin_fullscreen_gfxdrv_init(int w, int h, int vw, int vh, int color_depth);
@@ -98,7 +97,6 @@
0,
FALSE
};
-#endif
@@ -109,9 +107,7 @@
{ GFX_XDGA2, &gfx_xdga2, FALSE },
{ GFX_XDGA2_SOFT, &gfx_xdga2_soft, FALSE },
#endif
-#ifdef ALLEGRO_XWINDOWS_WITH_XF86VIDMODE
{ GFX_XWINDOWS_FULLSCREEN, &gfx_xwin_fullscreen, TRUE },
-#endif
{ GFX_XWINDOWS, &gfx_xwin, TRUE },
{ 0, NULL, 0 }
};
@@ -138,7 +134,6 @@
-#ifdef ALLEGRO_XWINDOWS_WITH_XF86VIDMODE
/* _xwin_fullscreen_gfxdrv_init:
* Creates screen bitmap (with video mode extension).
*/
@@ -146,4 +141,3 @@
{
return _xwin_create_screen(&gfx_xwin_fullscreen, w, h, vw, vh, color_depth, TRUE);
}
-#endif