[SDL] Window/surface dimensions mismatch problem
phillips at arcor.de
Tue Jan 14 11:52:01 PST 2003
On Tuesday 14 January 2003 14:40, Bob Pendleton wrote:
> On Mon, 2003-01-13 at 16:38, Daniel Phillips wrote:
> > ...X is telling SDL that the window is 640 x 480, even
> > though it is displaying some other size. I say "displeasure", because if
> > I'd been able to detect the mismatch at this point I'd be well on my way
> > to producing a patch by now. As it stands, I have to admit that the
> > mechanism involved is more convoluted than I thought. It probably
> > requires exploring the KDE and/or QT source, which would be more of a
> > time commitment that I was expecting. Bob, perhaps you can shed some
> > light on this?
> I know I replied privately, but for the rest of you, what can I say, I
> haven't been following this thread. And, I've either never run into, or
> never noticed this problem. Could be because I use GNOME, but I doubt
> Could you explain how you know the displayed size is wrong?
It's plainly visible on the screen. Either there is a black border around
the OpenGL surface, or only part of my OpenGL surface is displayed. SDL
returns and clamps the mouse coordinates consistently with the dimensions at
which it created the surface, in other words, inconsistent with the actual
I inserted debug output into SDL_PrivateMouseMotion, and by watching the
mouse coordinates, confirmed that SDL really thinks SDL_VideoSurface->(w,h)
are as specified in SDL_SetVideoMode and as returned by XGetWindowAttributes.
The latter is the real problem. What it means is that X is not telling SDL
the actual size of the created window, or at least, SDL has not asked the
right question. Perhaps there is more than one window involved, and the
"real" window is not the one handed back to SDL. I don't know, I haven't
really drilled into this yet.
I also have not tested this with a non-opengl SDL surface, though I believe
the result will be the same, as the same window creation mechanism is used.
I checked Xterm, and it is in fact fooled by a KDE "store settings" window,
as it does not generate linefeeds at the correct place, at least, not until
after it gets its first resize event. Strangely enough, the text output in
the terminal window is aware of the real size of the window, and wraps at the
correct place. However, Xterm will later overwrite some of the wrapped text.
This is a case of one part of X knowing about the real window dimensions and
another part (the Xterm application) not knowing.
Galeon gets it right - when starting up in a KDE "store settings" window, it
always dimensions the html rendering area correctly. Perhaps it is able to
do this because it remembers the last-resized window dimensions in a file in
your home directory. If so, that would require me to do a similar nasty,
disgusting hack, and I would only do that after investigating all other
possibilities. I don't think this is what's going on though.
Gfontview gets it right as well. After checking a few times, I did not
notice any disk activity associated with resizing or closing gfontview, so
here we have a good example of Gtk doing the right thing - somehow - whereas
SDL and Xterm do not. I'm interested in what the "somehow" mechanism is.
Now I have a choice of reading the KDE source, the GTK source to find out.
However, I thought it would be worth a try to save some effort, and see if
somebody out there already know's what's going on.
More information about the SDL