[SDL] Window/surface dimensions mismatch problem

Daniel Phillips 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
> it.
> 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 
window size.

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 mailing list