No announcement yet.

Pixel refresh rates for Pixxi 44 and 28 screens

  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Simplistically, all we are trying to do is avoid updating the internal memory at the same time as the low level driver is reading that memory to write it to the display.

    We do that by ensuring that the low level driver is processing a specified range of lines before starting our update to screen memory.

    Ideally, our update would take much less time than the time it takes the low level driver to read the entire screen's memory.

    In this case that is not so, so we try to time the 'crossover' point so that it occurs at a point when there will be no visible tearing as there will be no changes to memory at this point (on this screen it's in an area that is all white).

    The PmmC change made is permanent and will be in there for that display from now on. Other displays will have this functionality added on a case by case basis.

    At some point we will need to add support for this to Workshop, just need it to be exercised a few more times to fully understand what is needed.

    Simplistically, too many simplisticallies, for the easiest case, say your image was on lines 0-9 and was taking 30 lines to update on a 100 line display, all you would need to do is use disp_Sync values that would wait until the scan line was somewhere between 10 and 70 before starting the update. This is made more complex since this is usually a delay between line 100 and line 0, this delay varies from display to display, sometimes it is quite short and sometimes it is quite long.

    So, really, the scanlineSpeedo2 test program, is probably the easiest way to find working values for every case. We'll just have to play it by ear for a while.

    In my mind I can see a calculator that could be put in Workshop, but I think your case where update time is greater than scan time is probably the more likely case, and that is not calculable.