Re: jumpy scrolling on the Mac

Currently I'm not coding with FOX, but I've been writing software on
many different platforms for roughly 40 years. I watched your video and
read the reply from dpeterc. It probably is an XQuartz specific issue
like they say . . . but . . .

Where are you getting your data from?

I see this a lot with new developers and the occassional developer that
just wasn't thinking. They do database/file I/O and __wait__ for its
completion rather than catching a signal it has completed via some
connected callback. With a tiny amount of data it works even on an
underpowered test machine. Then you get production levels of data.
Things jerk, hang, appear to lock up, because there is some form of
data/network I/O blocking everything.

I do like the two solutions dpeterc proposed. I have no idea how to do
such things on Mac because I never write software for that platform. I
have worked on many low powered embedded devices and I can tell you
that caching any image, even a solid background color, and BLITting it
onto the screen can give you a snappy UI on a machine that has no GPU,
like this one.

https://www.hillrom.com/en/products/connex-spot-monitor/

Although we used Qt 4.8 for that, the concept is the same. So is the
solution. You have to develop for your least capable platform (Mac),
then cross compile the solution for better more capable platforms.

To support the hardware management wanted to base the above unit on, we
had to code our own base Widget, completely replacing the default paint
method provided by Qt so we could BLIT from caches. The built in image
caching wasn't enough.

Just my 0.0002 cents.

On Tue, 2024-05-21 at 16:45 +1000, Mathew Robertson wrote:
> Is a solution to this simply force a repaint() say after 100ms ? see
> below.
> 
> And/or could FXApp.cpp detect a "slow repaint" scenario, say by
> measuring the time between chores ?
> 
> cheers,
> Mathew Robertson
> 
> 
> FXMAPDEF(...this-class...)   this-class[] = {
>   ...
>   FXMAPFUNC(SEL_COMMAND,FXScrollArea::ID_HSCROLLED,this-
> class::startRepaint);
>   FXMAPFUNC(SEL_TIMEOUT....this-class::doRepaint)
> }
> 
> this-class::startRepaint(...) {
>     getApp()->addTimeout(.... window->repaint()   ... );     // <--
> obviously need to remove-repaint if the scroll-event is stopped.
> }
> 
> this-class::doRepaint(...){
>    getApp()->repaint();
> }
> 
> 
> On Tue, 21 May 2024 at 10:02, Jeroen van der Zijp
> <[email protected]> wrote:
> > On Mon, 20 May 2024 18:48:20 -0400
> > "John Selverian" <[email protected]> wrote:
> > 
> > > I'm running XQuartz 2.8.5 (xorg-server 21.1.6) and the scrolling
> > > is very jumpy. The text gets blurred until the scrolling stops.
> > > Other apps not using X11 are fine when they scroll.
> > > 
> > >  
> > > 
> > > I posted this to the XQuartz site with a short video:
> > > 
> > >  
> > > 
> > >  
> > > 
> > > https://github.com/XQuartz/XQuartz/issues/397#issuecomment-212073
> > > 4621
> > 
> > I can't say what the problem is, but my gut feeling says it has
> > something
> > to do with events piling up somewhere.
> > 
> > FOX tries to be very efficient processing events: we're pulling the
> > event
> > queue dry, and only start drawing when we catch up.  XExpose events
> > are
> > piled into the "repaint list"; rectangles which touch or overlap
> > are
> > consolidated, if the new area is less than the sum of the two old
> > areas.
> > 
> > So, onces it starts painting, it actually paints less rectangles
> > than
> > originally were received.
> > 
> > If a widget gets scrolled, parts of the window may have not getting
> > repainted yet.  FOX solves this by elongating the to-be-repainted
> > areas in the direction of the scrolling, and bitblits the rest.
> > 
> > Thus, we keep compounding dirty-rectangles until paint-time.
> > 
> > This works pretty well, and prevents processing of the event loop
> > from falling behind.
> > 
> > This may feel counter-intuitive, but redrawing is often more
> > expensive
> > than processing regular events, so deferring this until we've
> > caught up
> > with the event stream means we're never in the position of
> > redrawing
> > something that we may ALREADY know to be have to be redrawn AGAIN. 
> > [think of multiple consecutive scrolls].
> > 
> > So what are we seeing in the video? we're seeing LOTS off
> > scrolling,
> > and the system keeps piling up (or growing) repaint rectangles, not
> > being able to catch up.
> > 
> > Possible causes:
> > 
> >         1) Extremely high event rate from mouse?
> > 
> >         2) Slow drawing?
> > 
> >         3) Very high refresh-rate screens?
> > 
> >         4) Other callbacks going on preventing the system to reach
> >            the "idle" state, i.e. select() or pselect() returning
> >            with NO events. 
> > 
> > On my i5-8500T with 165 Hz screen (2K), using iGPU, it has no
> > trouble
> > whatsoever to smoothly keep up.  
> > 
> > So it must have something to do with how Apple does things, or may 
> > depend on something going on inside the application.
> > 
> > To rule out your application, may load a bunch of text into the
> > Adie
> > text editor and scroll it vigourously. If you seen the same
> > problem,
> > it may be the Apple issue; if the problem is confined to your app,
> > then some profiling may help.
> > 
> > 
> >    -- JVZ
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Foxgui-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/foxgui-users
> _______________________________________________
> Foxgui-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/foxgui-users

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

_______________________________________________
Foxgui-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/foxgui-users