iLiad xepdmgr - another approach to auto-refresh

[Antartica]

ericshliao, pwarren:

Attached is a new version of xepdmgr (v1.9h).

Changes:
- hopefully fixes the disable-autorefresh feature (Refresh() is now only called when autorefresh is not disabled).
- xepdmgrclient.c is now compilable as C++ (used pwarren's post as a guide for the changes).

Could you please test if in this version the autorefresh-disable works? Thanks a lot.

P.S.: Sorry for the very late reply...

P.S.2: After using a dillo with xepdmgr, I think that there are some bugs left in the dirty area tracking. If I manage to get some time next week I'll try hansel's proposed approach to dirty area tracking (that is, instead of maintaining a list of dirty rectangles, (1) divide the screen in MxN blocks (2) mark the dirty ones in a "dirty array" (3) count the number of marked elements when we have to refresh to know if we have to do a Full or Typing refresh).

[ericshliao]

I will write a small program to test this function.

Added:
It seems working. This is the test program, and source code is included. Unpack the attachment to your MMC or CF and a dir "xepd" will emerge. Execute the test program from contentlister. Clicking on "Auto-refresh Enabled" will disable auto-refresh, then users have to click on the pagebar to refresh the screen manually. And "Auto-refresh Enabled" will be changed to "Auto-refresh Disabled". Clicking on the same button again will enable auto-refresh.

Added 2:
I can't compile xepdmgrclient.c, so I copied all code of xepdmgrclient.c.

[ericshliao]

I have a question:
In the example given by Antartica, there is a line "if((Epd=EpdInit(NULL))=NULL)", and before v1.9h I used this line wihout modification. For v1.9h, I got compilation error at that line, so I modified it as "if((Epd=EpdInit(NULL))==NULL)" and I put it in my test program.
Will that line affect using auto-refresh? Did it cause failing to disabe auto-refresh before?

[Antartica]

Originally Posted by ericshliao

I have a question:
In the example given by Antartica, there is a line "if((Epd=EpdInit(NULL))=NULL)", and before v1.9h I used this line wihout modification. For v1.9h, I got compilation error at that line, so I modified it as "if((Epd=EpdInit(NULL))==NULL)" and I put it in my test program.
Will that line affect using auto-refresh? Did it cause failing to disabe auto-refresh before?

The first one should get an "invalid L-value" compiler error, it's a mistake on my part. The modification you propose is correct; that was the intended line.

About that mistake making the program not working: I don't know how it passed the compilation for the erroneous line; in principle Epd shouldn't become NULL because the parenthesis, but as that is incorrect C, the compiler could have interpreted it as without parenthesis... and then Epd would become NULL, making program to fail to send commands to xepdmg. Nevertheless it's very strange that it managed to compile that erroneus line of code :-?

I can't compile xepdmgrclient.c, so I copied all code of xepdmgrclient.c.

Can you paste here the errors you got?

Thanks for your testing

[ericshliao]

For "if((Epd=EpdInit(NULL))=NULL)", sometimes I got l-value error, and sometimes the compilation just passed. It's strange.

When I compile xepdmgrclient.c, I got:

gcc -o xepdmgrclient xepdmgrclient.c -lX11 
/scratchbox/compilers/oe/bin/../lib/gcc/arm-linux/3.4.4/../../../../arm-linux/lib/crt1.o(.text+0x30): In function `_start':
init.c: undefined reference to `main'
collect2: ld returned 1 exit status

[ericshliao]

Originally Posted by ericshliao

Just found something interesting.
In djview4 with xepdmgr, when I flipped the page, there was always a redundant screen refreshment even after the page was properly displayed. That is, to display a page, the screen refreshes two times in a second, even though the first refreshment already does pretty well.

As to the flickering problem in fullscreen mode, I found a solution.
Djview4 puts all update actions into a queue, but with this line: "QTimer::singleShot(0, this, SLOT(updateActions()));", Djview4 will ask QT do the update in real time. On desktop PC, it will generate good result, but on iLiad, it will cause flickering. So I modified that line to "QTimer::singleShot(400, this, SLOT(updateActions()));" and the flickering problem disappeared.
Since I can't find the return point of all update actions, I can't use the approach of disabling and then enabling auto-refresh of xepdmgr for such scenario.

[Antartica]

Originally Posted by ericshliao

For "if((Epd=EpdInit(NULL))=NULL)", sometimes I got l-value error, and sometimes the compilation just passed. It's strange.

Certainly strange. Ok, on to other matters...

Originally Posted by ericshliao

When I compile xepdmgrclient.c, I got:

gcc -o xepdmgrclient xepdmgrclient.c -lX11 
/scratchbox/compilers/oe/bin/../lib/gcc/arm-linux/3.4.4/../../../../arm-linux/lib/crt1.o(.text+0x30): In function `_start':
init.c: undefined reference to `main'
collect2: ld returned 1 exit status

That is because xepdmgrclient.c doesn't have a main() function, and you are trying to get a program (xepdmgrclient.c is only a library, you have to link it with your program). If you want to test the library compile xepdmgrtest.cpp ("make xepdmgrtest").

[ericshliao]

Originally Posted by Antartica

That is because xepdmgrclient.c doesn't have a main() function, and you are trying to get a program (xepdmgrclient.c is only a library, you have to link it with your program).

My original intention was to compile it to an object file. But I have too few knowledge using gcc. So I included (or copied) "xepdmgrclient.c" and "xepdmgrclient.h". It's working, but not in an elegant way.

[Antartica]

Originally Posted by ericshliao

My original intention was to compile it to an object file. But I have too few knowledge using gcc. So I included (or copied) "xepdmgrclient.c" and "xepdmgrclient.h". It's working, but not in an elegant way.

To compile it into an object file:

gcc -c xepdmgrclient.c

That will produce "xepdmgrclient.o", that you can link with your program.

If anything needs more explanations, don't hesitate to ask .

[ericshliao]

I am thinking about whether LED control code in xepdmgr is necessary. If we add LED control code in applications ported to iLiad, then it is redundant for xepdmgr to control LED flashing. If we don't add LED control code in applications, then LED will go wild during user's operation. So, it seems that xepdmgr can ignore LED and leave it for idividual application to deal with.

[Antartica]

Hi!

Attached is xepdmgr v1.9i

Implements the dirty area management using Hansel's proposal of just dividing the screen in blocks and tag the dirty ones (see start of this thread O ).

This fixes the problems where xepdmgr was doing a Typing refresh when a full refresh was better (most of the screen changed). Now xepdmgr does a Typing refresh when only part of the screen is changed and a Ful one when almost all the screen has changed.

Enjoy!

[ericshliao]

Just tried 1.9i, working fine.
Take djview4 for instance, when I tap on menu-bar, a menu-item list will drop down, that means only a small rectangle on the top-left of screen needs redraw. Ideally, I guess 1.9i will do a partial refresh in this scenario, but the result is the same with 1.9h, the whole screen got refreshed.

[hansel]

@Ericshliao: There will never be real partial updates: it is not implemented in the driver (see replies 81;82). Somehow, Irex never got to implement it

EDIT: maybe we should infiltrate in the Irex development team (http://www.irextechnologies.com/about/jobs)


What xedpmgr tries to do is: use the quick (and dirty, some ghosting, less grey levels) update for small changes, a full refresh (long, white flash first) for big changes. I'm afraid this is the best we can do...

Happy coding nevertheless!

@Antartica: I found an even simpler (and better) way to decide about the update: just add up the areas of all damaged areas, and check this total in a timed loop. Do a 'full' update if the total area gets bigger than some limit, a 'typing' update otherwise (and of course nothing if nothing changed). See https://dev.mobileread.com/trac/luai...ts/XX/main.cpp for my experimental implementation).

This approach has the advantage that a lot of small changes at the same location give a full update once in a while (the display get ugly otherwise):

[Antartica]

Originally Posted by ericshliao

Just tried 1.9i, working fine.
Take djview4 for instance, when I tap on menu-bar, a menu-item list will drop down, that means only a small rectangle on the top-left of screen needs redraw. Ideally, I guess 1.9i will do a partial refresh in this scenario, but the result is the same with 1.9h, the whole screen got refreshed.

Yep. As Hansel said, the problem is that partial refreshes aren't implemented in the display driver of the iliad.

BTW, thanks for the testing (once more! ).

But I have an idea that, if it works, will allow us to overcome that limitation: brushes are indeed implemented (they are used for the progress bars and for the scribble library). If uploading brushes is fast enough, we could paint very small changed areas by uploading a brush of the "screenshot" of the changed area and using it.

Originally Posted by hansel

@Antartica: I found an even simpler (and better) way to decide about the update: just add up the areas of all damaged areas, and check this total in a timed loop. Do a 'full' update if the total area gets bigger than some limit, a 'typing' update otherwise (and of course nothing if nothing changed). See https://dev.mobileread.com/trac/luai...ts/XX/main.cpp for my experimental implementation).

This approach has the advantage that a lot of small changes at the same location give a full update once in a while (the display get ugly otherwise):

Mmmm... interesting. Will think about it . Thanks :-b.

[ericshliao]

The term "partial refreshing" is causing confusing. I should not use it. What I meant was that I expect a quick refresh (with ghost effect) when menu-item list dropped down. I saw such refreshing result in window-mode of djview4. I guess it should be "typing refresh".
In window-mode of djview4, even though page-content occupies 95% of the screen, I still got quick refreshing (not the whole screen got refreshed) when flipping page. So I expect the similiar refreshing for menu-item operation.