Re: updating FXCanvas

On 2023-10-04 20:39, John Selverian wrote:
> When a user clicks a button a new window opens and several plots are
> displayed on a FXCanvas. When the plot has up to about 30 curves
> everything works fine. When I make more than about 50 they do not
> display when the new window first opens. I have to refresh the window
> for the plot to display. I have a timer with a 0.5 s delay to allow
> the plot to be drawn. I've increase this to 5 s with no effect. I've
> also tried for force it with no effect:
> 
> _canvas->update();
> 
> _canvas->forceRefresh();
> 
> I only see this problem on Windows, on the Mac and Linux it does not
> matter how many curves are displayed, they show up when the window
> first appears.
> 
> Any ideas?

Neither of these two APIs actually paints.

widget->update() adds a repaint rectangle (the whole widget, or
a sub rectangle of it).

widget->forceRefresh() forces a GUI update callback from all widgets
in the subtree below widget (this includes widget itself).

The system will process events, and dispatch them, until the event queue
eventially becomes empty.  At that point, the repaint rectangles are
processed to draw widget contents on the screen.

Eventually, both the event queue and the "repaint queue" become empty
and the system block, to be awakened by either a timer or a user input
event, or some other thing like a network socket.

If there is ALWAYS something to do, we'd never get around to redrawing.
Possible causes for this:

1) you have a huge number of timer events, and there's always one due
whenever getNextEvent() is called.  I think its a known weakness,
although none of my apps ever have run into this.

2) There are always GUI events.  This is unlikely, as the highest-
rate event source is your mouse.  Even high-rate mice only deliver
something like one report/ms (ballpark).

3) You have a some sockets being watched by the main event loop, and
possibly, one of these sockets remains signalled:

a) read socket is signaled when there's fresh data.  Once all data has
been consumed, its becomes unsignaled.  This makes a read-socket not
a likely source of the problem.

b) write socket is signaled when the write-buffer has room.  This means
its usually signaled except when the connection is very slow to send the
data.  Adding a write socket to FXApp using addInput() may not be very
useful, unless you do asynchronous I/O and set the socket to 
non-blocking.
After a (partial) write, you can add the socket. Then, when FXApp sends
the SEL_IO_WRITE you write some more, and if all the data has been sent
then remove the socket from FXApp using removeInput().

If socket IO is what you're doing, a suggestion is to maybe let another
thread deal with the socket IO, and let FXApp just deal with GUI
related events.

Without knowing more, I can't really say what your causes your problem.

    -- JVZ