possible idea for alternative screen refresh strategy

[chris_c]

i'm presenting here my idea in the hope that someone might shoot it down so saving me coding time in possibly fruitless experimentation... !

While primarily for full screen refreshes it could do smaller areas.

As I understand the technolgy each pixel behaves almost as a relative device with its actual value drifting over time.

In order to get the pixel back to a known value the pixel is driven as black as it will go then as white as possible. This hopefully leaves it at zero ready to be set to the required level.

There is probably dedicated memory on the eink driver chip in the form of a back buffer to optimise this over a full screen (a guess)

Although my idea ay be slower I think it will be easier on the eye and even be mistaken for a fancy animation!

basically you do each operation one line (vertical or horizontal ) at a time

1 draw a line as dark as possible even over driving it if somehow possible.
2 draw a fully white line over the top of the last line
3 on the newly cleared line draw 1 line of new screen content
4 if not finished move down 1 line and continue from step 1

while slower it should still be feasible and although technically flashing it should be a lot less distracting...

Any thoughts?

[twobob]

EDIT: Err no. my bad.

Spoiler:

see GM Video driver. add ordered dither and you're there

EDIT: Okay I had a quick look again, in essence pure black draws much quicker as you have identified, so here we avoid grays.


I just ripped out the relevant method: (this is 8bit K5 one, but w/e)

I have mercilessly ripped out bits to demo what you are talking about

PHP Code:

void gmplay8() {

//check out the original code but...
in essence we are defining what we are to draw inside, 
to what depth etc... (FBSIZE IS #define FBSIZE (600/8*800))
Also we have to tell it the exact types etc..
u32 __invalid_size_argument_for_IOC; // ioctl.h bug fix for tcc

    u32 i,x,y,b,fbsize=FBSIZE; u8 fbt[FBSIZE];

// Read it in...

    while (fread(fbt,fbsize,1,stdin)) { 

// Sync code elided.... sufficed to say it can drop frames...
 

//So jump every 8 lines...
        for (y=0;y<800;y++) for (x=0;x<600;x+=8) {

do order bit dither over 100 passes 8 pixels apart

            b=fbt[600/8*y+x/8]; i=y*fs+x;
            fb0[i]=(b&1)*255; b>>=1; fb0[i+1]=(b&1)*255; b>>=1;
            fb0[i+2]=(b&1)*255; b>>=1; fb0[i+3]=(b&1)*255; b>>=1;
            fb0[i+4]=(b&1)*255; b>>=1; fb0[i+5]=(b&1)*255; b>>=1;
            fb0[i+6]=(b&1)*255; b>>=1; fb0[i+7]=(b&1)*255;

// Update the frame count and pass an update enum to the lib...

        } fc++; gmlib(GMLIB_UPDATE);
    }
} 


// Etc..

More full details and someone who knows what they are talking about on this thread:
HTH

https://www.mobileread.com/forums/sho...d.php?t=177455

[twobob]

Some more wrongness. just for good measure:

Spoiler:

In essence you are talking about "Dirty Rect" on a per pixel approach if I'm not mistaken. ( probably am ) But assuming the entire screen is dirty?

I'm not 100% what the hell I am talking about


Are you saying some sort of backbuffer logic pass to "Glean" what state the pixel might be in?

or is it an assumption that simply passing through the various pixel states (as said in OP) will eventually end up where you want to be (remember Gray is SLOW)

is that it in a nutshell?

AFAICT GM still has to pass a call to eips to get stuff to finally splat to the screen in a last pass, but again I could be wrong

(just assume the shorthand declarations are enums, structs or typedefs and you can read GM's code with not too much hassle)

PHP Code:

if (GMLIB_INIT==op) { teu=getmsec(); fdFB=open("/dev/fb0",O_RDWR);
        ioctl(fdFB,FBIOGET_VSCREENINFO,&screeninfo);
        ppb=8/screeninfo.bits_per_pixel; fs=screeninfo.xres_virtual/ppb;
        VY=screeninfo.yres_virtual; MX=screeninfo.xres; MY=screeninfo.yres;
        ua.x2=MX; ua.y2=MY; ur.update_region.width=MX; ur.update_region.height=MY;
        fb0=(u8 *)mmap(0,MY*fs,PROT_READ|PROT_WRITE,MAP_SHARED,fdFB,0); // map fb0
        if (VY>MY) { eupcode=EU50; eupdata=&ur; ur.update_mode=0;
            if (ioctl(fdFB,eupcode,eupdata)<0) { eupcode=EU51; eupdata=&ur51; }
        } else { eupcode=EU3; eupdata=&ua; }
        system("eips -f -c;eips -c"); sleep(1);
    } else if (GMLIB_UPDATE==op) {
        if (ioctl(fdFB,eupcode,eupdata)<0) system("eips ''");  // 5.1.0 fallback
    } else if (GMLIB_VSYNC==op) { while (teu>getmsec()) usleep(1000); // fb0 busy
    } else if (GMLIB_CLOSE==op) { gmlib(GMLIB_UPDATE); sleep(1); // last screen
        system("eips -f -c;eips -c"); munmap(fb0,MY*fs); close(fdFB); 


So there will probably be a bit of that in our future too...

Again HTH

[MaPePeR]

I think you are completely mistaken, what he wanted to say.

He suggested that instead of making a full-black/white-flash after a page turn to only flash each line of the display.
This would result in the page being rendered a bit slower from top to bottom, but would avoid the distracting full-flash.

(I came up with that idea myself a short time ago, but it has nothing to do with gm-videoplayer. It only affects the Page-Turn-Flash/Refresh)

[geekmaster]

Back before I created the "formula 42" dithering (when I got my first K3), I did an unpublished "proof of concept" demo where I attempted to do a line-by-line refresh to wipe a full-refresh image on top of a previous image. I discovered that by drawing each line as all black then all white, and repeating about 20 times, you can end up with a line that is significantly whiter than even repeating three full-flash clears. And after shaking the black and white particles back and forth many times between black and white like that, you can also end up with much blacker than a full black screen after multiple full-flash clears.

While playing with that code, I also discovered an undesirable side-effect. The eink display consists of many tiny beads for each pixel. Each bead contains many black and white oppositely-charged particles. The charged particles are attracted to opposite front and back surfaces when an electric charge between tiny row and column grid wires on the front and back screen surfaces. That makes the charged particles move to the front or back by electrostatic attraction. Grays are made with complex alternating current waveforms applied to the grids to leave a controlled complex mixture of charged particles behind. The undesirable side-effect of the electrostatic attraction method of controlling charged particles is that an electric field spreads out in space and weakly affects nearby beads in adjacent pixels. This causes a slight ghosting halo around stuff, which you can see if you draw a black line on a white background and then draw an identical white line on top of it (which leaves a slightly visible "gray halo" outline around it). Another way to see it is to draw a filled black square, then delay a bit, then draw another fillied black square next to it, forming a black rectangle. You will be able to clearly see the seam between the two squares, because some electric charge from the second black square made the edge pixels of the first square even "more black" (blacker than black). From this test, I started a new demo (which never got past the "proof of concept" stage and was not yet published).

I was able to display quite visible white letters on top of a pure white background that had been erased multiple times with full-flash updates, and I was able to display quite visible black letters on top of a pure black background. I was going to call it my "whiter-than-white/blacker-than-black" demo (or some cute name to imply that). But I did not clean it up enough to publish it.

Anyway, the point of this story is that you CAN do a full refresh WIPE of one image onto another (which is what this thread is about), but there can be visible side effects beyond the fact that it takes MUCH more time to do than the built-in full-screen full-flash update. However, by controlling the line-by-line refresh to create blacker-than-black and whiter-than-white, you can create a much higher-contrast image on the display than by normal methods (and it looks even better on the K4 and K5, which normally look somewhat low contrast when compared side-by-side with a K3).

EDIT: If you want to repeat my experiments, you need to adjust the delay between line redraws, to allow each one to complete before starting the next one. Also, the "formula 42" dither method may be more appropriate for experimenting with this stuff than hacking the gmplay code.

EDIT2: There is certainly room for more experimentation in this area, so be sure to post your results.

EDIT3: What I described above was done in a "native mode" app (scripting in this case, which I planned to convert to C some day). It could be added to other native mode apps such as hawhill's muPDF project, but would be more difficult to add to the desktop framework.

[giorgio130]

@Geekmaster, I know this is a little off-topic but here we go: I have a K3 that displayed for a long time (I don't know how much) the same image and now it has some "ghosting", whatever it displays it keeps showing some trace of it. Do you think that a script that keeps refreshing the screen would improve the situation?

[geekmaster]

Originally Posted by giorgio130

@Geekmaster, I know this is a little off-topic but here we go: I have a K3 that displayed for a long time (I don't know how much) the same image and now it has some "ghosting", whatever it displays it keeps showing some trace of it. Do you think that a script that keeps refreshing the screen would improve the situation?

Yes.

Warm it up to about 25C, and then do at least 3 (perhaps up to 20) full flash screen clears ("eips -c" on a K3). After getting cold, or sitting awhile, the eink displays take awhile to warm up to the ideal oil viscosity in the beads that contain the black and white charged particles.

Exercise it until it improves. Put a short delay between refreshes (about a half-second).

[twobob]

mmk. well the GM video player doesn't appear to "flash" to me. perhaps it does.

Hence the thought. : ) cheers

[geekmaster]

Originally Posted by twobob

mmk. well the GM video player doesn't appear to "flash" to me. perhaps it does.

Hence the thought. : ) cheers

Depending on what video you play, some of the videos would definitely give the eink a bit of warmup exercise (especially the 4:3 fullscreen videos). Letterboxed video would give part of the screen very little exercise, perhaps leaving some ghosting behind.

I strongly recommend the original gmvid.gmv.gz "geekmaster signature" video, which continuously changes all of the pixels on an 800x600 display. It should work nicely after that for ebook reading.

[chris_c]

All this talk about displays has reminded me of a humorous anecdote - I must set the scene for those of you not in the UK....

Over here we have a chain of shops we'll call them Personal Computer Globe Ltd.... they like to cultivate the air of being "experts" with everything tech - which is amusing just in its self after you've been exposed to the pimply faced bull****ing box shifters...

Anyhow I decided to treat myself to a K5 (girlfriend inherited my K4) being occasionally an impatient sort I decided rather than wait for the post, I'll just swing by a shop and quickly pick one up...

They decide as usual to aggressively push their insurance in declining their +30% extra the sales rep launched into the spiel about how delicate the screen was to the point that the only thing that would shut him up was me asking if I shouldn't buy it then...

I decided to forgo my usual argument about statutory rights and the sale of goods act, I just really couldn't be bothered.... But I thought I might as well get some amusement for my extra wasted time

"SO...." I ask "how do these displays actually work then ?"

Let me tell you if you thought you knew I'm about to set you right...

"well what it is" he said with total authority "there's like this magnet that goes quickly up and down the screen making some of the ink stick to the glass."

I actually managed to keep a straight face "So its like an etch-a-sketch then?"


I wish I'd been recording it....

[geekmaster]

We have local "computer experts" working at big box techno chain stores here. Their logo looks rather "familiar" (Geek "something" as I recall). They behave much the same as you experienced. They give totally BS answers to tech questions (especially the "managers" who are quick to call YOU an idiot and claim that YOU broke the power supply by renaming the internal disk partitions) in the computer your client bought from them. Yes, that literally happened to me while trying to get warranty repair for a client's computer. I renamed the hard drive partitions after adding extra external drives for a client, so they could easily tell which drive was which when Windows decided to resequence the drive letters depending on which (if any) USB drives were plugged in when you booted the computer. [The external drives had their own power supplies, so the dead computer power supply was probably just a coincidence.]

Anyway, some in-store tech support personal are abusive and condescending idiots.