[Qt-interest] Critical bug: QWidgets with size > 16383 break on OS X

[Nikos Chantziaras]

On 06/24/2010 04:20 PM, Constantin Makshin wrote:
> On Thursday 24 June 2010 14:43:45 Nikos Chantziaras wrote:
>> On 06/24/2010 01:26 PM, Constantin Makshin wrote:
>>> To be honest, I'm not sure this bug is *that* serious. Screens
>>> are still much smaller than 8191 pixels in any dimension, even
>>> in multi-screen configurations AFAIK.
>>
>> You don't understand.  A widget that is big has scrollbars.  If
>> you visit a web page, the rendered document is much bigger than
>> your screen. It's like saying that web pages should never be bigger
>> than your screen and to never use scroll bars.
>>
>> As you can guess, a web page or any other document should be able
>> to be higher than 16 thousand pixels.  It's a serious limitation
>> otherwise, and hence why I consider this bug serious.
> Bad example. At least in Qt text editing/viewing widgets (except
> labels, buttons and other widgets that don't support scroll bars by
> design) and widgets that render web pages are smart enough to keep
> their size independent of web page contents. They either render the
> whole page into some off-screen buffer and display only visible part
> of it or simply don't render invisible parts of the page at all.

That's what QScrollArea is there for.  Only the viewport() is rendered. 
  Everything else, no matter how big the contained widget is, is not 
rendered at all.  Only the visible part receives paint events.

This is the whole point of it :-)  Having a large widget inside a 
QScrollArea is a convenience so that you don't have to deal with 
coordinate transformations (documents coordinates to viewport 
coordinates.)  Qt takes care of that for you so that you only need to 
work with document coordinates.


>>[...]
>> Qt4 promises to allow widgets of arbitrary sizes without any
>> overhead. It was one of the advertised features when Qt4 came to
>> replace Qt3.  And it doesn't work on OS X :-/
> I know that (at least 4.x branch) uses its own methods to handle
> widgets.
>
> But look at "src/gui/kernel/qwidget_*" files in Qt source package or
> at http://qt.gitorious.org/qt/qt/blobs/4.7/src/gui/kernel/ . Most of
> them have either macro or constant named "WRECT_MAX" equal to 8191
> for Mac OS and X11 and 16383 for other platforms.
>
> And if you read the description for void
> QWidgetPrivate::setWSGeometry() function in "qwidget_mac.mm" file,
> you'll find this: "Helper function for non-toplevel widgets. Helps to
> map Qt's 32bit coordinate system to OS X's 16bit coordinate system.
> Sets the geometry of the widget to data.crect, but *clipped to sizes
> that OS X can handle*." (this function in "qwidget_x11.cpp" has
> similar description)
>
> All this really makes me think it's some sort of platform limitation.
> Of course, it'd be very nice (and much more useful than these
> assumptions) to get more or less detailed explanation from Qt
> developers.

These are internal implementation issues that the Qt user should not 
know (or care) about.  All I need to know is that Qt is supposed to 
deliver 32-bit coordinates everywhere but doesn't do so.  Therefore a bug.