On Tue, 2010-08-24 at 14:32 +0200, m0n0 wrote:
> Hello,
>
> >> gui_poll should block on input untill the next timer event when there
> >> are no outstanding redraw requests to be performed and the active flag
> >> is false. An obvious example of this is the gui_poll() in
> >> framebuffer/gui.c
>
> This is an comment from the amiga port for GUI poll:
>
> /* However, down here we are waiting for the user to do something or
> for a
> scheduled event to kick in (scheduled events are signalled using
> timer.device, but NetSurf seems to still be wanting to run
> code. We ask
> Intuition to send IDCMP_INTUITICKS messages every 1/10s to our
> active
> window to break us out of ami_get_msg to stop NetSurf stalling (the
> active
> variable seems to have no real bearing on reality, but is supposed
> to
> indicate that NetSurf wants control back ASAP, so we poll in that
> case).
> */
>
>
> This is the windows poll function:
>
> void gui_poll(bool active)
> {
> MSG Msg;
> if (PeekMessage(&Msg, NULL, 0, 0, PM_REMOVE) != 0) {
> if (!((current_gui == NULL) ||
> (TranslateAccelerator(current_gui->main,
> current_gui->acceltable, &Msg))))
> TranslateMessage(&Msg);
> DispatchMessage(&Msg);
> }
> schedule_run();
> }
>
> seems it returns immediately in any case, no matter if active or not.
>
> To me it looks like this needs some clarification (especially the amiga
> comment) O:)
It's perfectly fine to return immediately if you want to: you'll just
waste CPU cycles spinning, which is pretty much what the Windows
frontend does.
The Amiga frontend is more intelligent and will block until a timeout
occurs, so it can trigger scheduled events as appropriate.
The framebuffer frontend is more intelligent still and will block until
the time at which the next scheduled event should occur, at the latest.
In all cases, any events generated from outside the application (e.g.
user input) will be handled immediately, as the expectation is that the
windowing system will deliver them in a timely manner.
J.
