+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: HP Prime (/forum-5.html)
+--- Thread: Screen refresh question (/thread-1028.html)
Screen refresh question - orcinus - 04-02-2014 10:53 PM
Is there a reason why the whole screen gets refreshed (resulting in an annoying flicker) on every single keypress? This being the year 2014 and double buffered graphics being a common thing?
Even if buffering is not an option, why refresh the whole screen? And why for every keypress?
In fact, the various graph apps never refresh the menu bar at least (just the plot area). Home screen, Apps etc. go through repainting the whole shebang, the menu, the status bar, everything.
It's a minor and purely cosmetic annoyance, but it makes the product look cheap.
RE: Screen refresh question - eried - 04-03-2014 02:49 AM
Yeah is really annoying and looks cheap but I am fairly sure isn't something so simple like *click* enable double buffer, otherwise it would be already fixed.
RE: Screen refresh question - orcinus - 04-03-2014 03:36 AM
I'm aware it's not (that was just a poor attempt at cynicism), but preventing refresh of screen areas that don't require repainting and not repainting the whole screen for *every* keypress (even when no action has been made and there is no text entry) should be doable (i'm guessing).
RE: Screen refresh question - jte - 04-03-2014 05:30 AM
(04-02-2014 10:53 PM)orcinus Wrote: …In fact, the various graph apps never refresh the menu bar at least (just the plot area)….
The plot views of the graphing apps should be refreshing the menu bar when the menu bar changes. (E.g., by toggling “Trace”.) Have you seen instances where it fails to refresh? (When it should.)
The plot views of the graphing apps should be avoiding needless refreshes. Moving the cursor around, or tapping the cursor to jump to a location, should not — by itself — induce refreshing of the plot area. Only the pixels in the immediate vicinity of the cursor should be changing. (If the movement leads to scrolling, the pixels will get redrawn.)
RE: Screen refresh question - orcinus - 04-04-2014 01:25 AM
(04-03-2014 05:30 AM)jte Wrote: The plot views of the graphing apps should be refreshing the menu bar when the menu bar changes. (E.g., by toggling “Trace”.) Have you seen instances where it fails to refresh? (When it should.)
No, no, you misunderstood me.
It doesn't refresh *needlessly*, i.e. on graph scroll.
My question was - why don't the other views/screens/apps repaint the screen only where/when necessary *like* the plots.
RE: Screen refresh question - cyrille de brébisson - 04-04-2014 05:55 AM
Hello,
Multiple answers there...
- Backbuffers:
The problem with drawing in a back buffer is that this assumes basicaly instant drawing. Althrough this is the case most of the time, it is not always the case. Some calculations are slow (or very slow, or even never ends). Using a backbuffer do draw would cause in these cases a 'wait for it to draw' syndrom instead of a 'you see it draw effect'. It would also affect user programs that interract with the screen
- Selective redraw after key presses
The HP48 had such a system in place. And it was one of the hardest thing that the team did and one of the place where they had the most numbers of bugs. It was essencial to do it on the 48 which was (at least originally so slow), so they had no other choices. However, since prime is fast, it was not nessecary to do it, so we spent our time on other places of the system.
- We are working on it.
If you compare prime now with olders revision, you will see that there is less and less flickering happening. This is because we are (selectively) adding the use a backbuffer for drawing. But this is done on a per control basis, not on a system wide basis.
Cyrille
RE: Screen refresh question - orcinus - 04-04-2014 01:52 PM
Thanks for responding! And glad to hear there are still improvements to be made (and that are being made) on the roadmap
