Re: jumpy scrolling on the Mac

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