Do GTK+ apps benefit from multiple visuals?
- From: Tor Lillqvist <tml iki fi>
- To: gtk-devel-list gnome org
- Subject: Do GTK+ apps benefit from multiple visuals?
- Date: Sat, 2 Aug 2003 19:54:22 +0000
I am going through the gdk/win32 code a bit while adding support for
multiple monitors. One thing that I am looking at is what visuals GDK
presents to GTK and the application. Currently the code creates just
one visual, corresponding to the native format of the display (at the
time the app starts and GDK is initialized; the user might change it
on the fly later, but GDK doesn't notice).
Anyway, Windows does itself know how to handle pseudocolor (using X11
terminology here) API even if the display in fact is truecolor, and
vice versa. (Which can be seen by switching the display settings while
a GTK+ app is running.)
Of course, using truecolor while the display in fact is pseudocolor
means that Windows will have to do some heavy-handed dithering and
whatnot, and the results will not be pretty. (Certainly not as nice as
what gdkrgb produces.)
The other way around, though, shouldn't be any problem. If you use
pseudocolor even if the display in fact is truecolor, you will get
pseudocolor-looking output, but not any worse.
Are there GTK+ applications (that might be ported to Windows some day)
out there that prefer, or even require, pseudocolor visuals to be
present? Should GDK present also such a visual even if the display
really is truecolor? I remember that long ago X11 applications that
required pseudocolor were rather common, but can one assume that
nobody writes code like that any longer?
What about the other way, are there applications that require trueolor
visuals to be present? Should GDK present such a visual even if the
display in fact is pseudocolor? (Yeah, the number of machines running
displays in 256-colour mode is probably shrinking fast, but anyway.)
Finally, if I change GDK/win32 to present also "fake" visuals, is
there any way to indicate which visual is the "real" one, so that GTK
or applications would know to prefer it, unless they really really
want a specific type? (I mean, if the display really is pseudocolor,
the "fake" truecolor visual should be used only if the app really
cannot cope with pseudocolor.)
--tml
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]