On Fri, Jul 01, 2016 at 06:22:02PM +0100, Arnt Gulbrandsen wrote: > Hendrik Boom writes: > >One thing I'm wondering about with GTK3 -- does GTK3 have the annoying > >16-bit limitation on pixel counts? That has bitten me with GTK2. It > >severely limits one's scrolling range. > > JFYI, it's not actually severe. Looks that way until you've crossed it, > that's all. > > There's an easy workaround: Scroll in n-pixels steps instead of pixels. If > you scroll in, say, 16-pixel steps, users won't notice the loss of accuracy, > but you'll have an 19-bit or 20-bit range (the 16-bit limit is sometimes > 15-bit because of sign bits). But it doesn't help you, because an 19-bit > range is so large that users lose the ability to use the scrollbar > effectively. Dragging the scrollbar one or a few pixels is an unmanageably > large jump on the model. At a 19-bit range with a 900-pixel scrollbar+view, > a single-pixel movement of the scrollbar moves the view by two thirds of the > window.
It isn't a question of scrollbar resolution. It's a question of the size of the scrolled region. The various keyboard keys such as page up and page down still worked, independent of the mouse and the scroll bars. But I had a large scrolled region. When the pixel counter for the scrolled region overflowed, GTK started drawing over previous information at the top of the scrolled window again. Messy. -- hendrik > > I think this workaround is so little-used and little-known precisely because > it doesn't help. It just bypasses the 16-bit limitation and immediately > gives you another, much less tractable, problem. > > Arnt > _______________________________________________ > Dng mailing list > [email protected] > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
