iLiad xepdmgr - another approach to auto-refresh

[ericshliao]

With a brief browse in the source code of Irex's modified gtk libs for DR1000, I found that they added some function (void irex_display_update) to send update request through socket. The question is: what's the destination? Which program is to receive the update message and perform the real update action? Right now, I haven't found it. Maybe it's not open source.

[hansel]

Originally Posted by ericshliao

..., I haven't found it. Maybe it's not open source.

xepdmgr?

[ericshliao]

Originally Posted by hansel

xepdmgr?

Of course not xepdmgr. Sorry for not stating my question clearly.

As indicated by Antartica, for DR1000, iRex adopted another approach to control screen-refreshment.
The modified GTK+ for DR1000 can be downloaded here:http://developer.irexnet.com/pub/iOn...-2.12.7.tar.gz.

In that package, among the files, I saw some lines of code in gdkwindow.c:

// IREX
// create connection to displayMgr
void irex_display_init(char addr[], int port) {
    if (irex_display_socket==-1) {
        irex_display_socket = socket(PF_INET, SOCK_DGRAM, 0);
        irex_display_addr.sin_family = AF_INET; 
        irex_display_addr.sin_port = htons(port);
        irex_display_addr.sin_addr.s_addr = inet_addr(addr);
        irex_pid = getpid();
        memset(irex_display_addr.sin_zero, '\0', sizeof irex_display_addr.sin_zero);
    }
}

// IREX
// send a display update message
void irex_display_update(int x, int y, int width, int height) {
    char msg[256];
    irex_display_init("127.0.0.1",50555);
    sprintf(msg,"!I,%d,%d,%d,%d,%d,%d,%d,%d,%s,%d", 
            irex_pid,
            x, y, width, height, 
            irex_dump_ignore,
            irex_dump_is_window, 
            irex_dump_window_type, 
            irex_dump_widget_type,
            irex_dump_focus);
    //printf("Sent update message: %s\n", msg);
    sendto(irex_display_socket, msg, strlen(msg), 0, 
            (struct sockaddr*)&irex_display_addr, sizeof(irex_display_addr));
    irex_dump_focus = 0;
}

From the above code, I guest that iRex modified GTK+ libs to make GTK+ send update message to some unknown DisplayMgr through socket. Then I tried to find that DisplayMgr, but I can't find it. That's what I meant in the previous post.

[hansel]

Originally Posted by ericshliao

Of course not xepdmgr. Sorry for not stating my question clearly.

Sorry for not explaining my hint clearly

What I meant is: find a spot in the QT libs that is called for all screen updates, and send a message to xepdmgr from there. (or insert a call to dmDisplay() as you mentioned earlier)

Good luck! Hans.

[ericshliao]

I had a faint feeling there is something correlated between xepdmgr and the approach adopted by iRex in DR1000, but I just don't know what it is and how to express it. I got your idea now. Thanx.

Maybe I should first try this approach on GTK+.

[ericshliao]

Just want to make sure one thing before I start. Instead of using xepdmgr, from the modded GTK+, I should call functions provided by xepdmgrclient (such as EpdRefreshFull(sEpd *Epd)). Right?

[Antartica]

Originally Posted by ericshliao

Just want to make sure one thing before I start. Instead of using xepdmgr, from the modded GTK+, I should call functions provided by xepdmgrclient (such as EpdRefreshFull(sEpd *Epd)). Right?

No. The functions of xepdmgrclient are to talk with xepdmgr.

To talk with displayMgr directly there is an open UDP port... look at the sources of xepdmgr or the ones of displayMgr.

[ericshliao]

Thanx so much. Fortunately I asked before trying.

My current progress: The modified GTK+ for DR1000 can be compiled with iLiad SDK without any problem.

[ericshliao]

I can build dillo2 on my desktop now. It still failed to dispaly Chinese and Japanese text. I also tried a hello world program, only English letters can be dispalyed. So, I guess the problem must be dealt within FLTK2.

[Antartica]

Originally Posted by ericshliao

I can build dillo2 on my desktop now. It still failed to dispaly Chinese and Japanese text. I also tried a hello world program, only English letters can be dispalyed. So, I guess the problem must be dealt within FLTK2.

I reply in the dillo thread (in Iliad software releases) .

[pwarren]

Hi all,

I've been thinking about my FBReader port, and getting it to turn pages faster. With xepdmgr only, it takes ~5 seconds for my test pages to display the new page, after using the flipbar, which is a little too long for comfort.

I've managed to port FBReader page display to the erdm way of doing things, and this brings it down to ~2 seconds, which is much more manageable.

The only trouble, is that with this version is that the widgets that you get from pressing the menu buttons don't work terribly well. The File Selection dialogues, and the configuration dialog are particularly useful.

So I thought that instead of trying to find every instance of things that needed porting there, I'd try and use a mixed approach, use xepdmgr for the menu button dialogues, and the erdm style for page flipping.

To my questions then

Is that pretty much what the EPDCancel() function is for?
and
How do I use that in FBReader? (or other code for that matter)

Cheers.

[ericshliao]

5-secs to 2-secs? That's really awesome.

I want to clarify something. Based on my understanding, there should not be a 3-secs difference between using xepdmgr and erdm. The real difference between using xepdmgr and erdm should be only 1 sec. 3-secs is too much.
Take ipdf for example, we can get a page refresh in 2 seconds because ipdf preload the next page and write the data to framebuffer while we are reading the current page. Then, when we flip the pagebar, erdm will draw e-ink screen based on the data stored in framebuffer. That's the fast response we can expect for iLiad. Because contentlister does not have such preloading and prefetching mechanism, we get page refreshment in 5-secs. In my homebrew text viewer with xepdmgr, I managed to get next page dispalyed in 3 secs (with preloading but no write to framebuffer). If no preloading, the next page will be dispalyed in 5 secs. And I believe if I implement preloading next page and prefetching data to framebuffer in background in my text viewer, I can get a 2-secs refreshment just like ipdf.

So, based on my current understanding and conjecture, you can get FBReader display next page in 2-secs only if you implement both preloading next page and fetching data to framebuffer. That's quite a complicate job.

[Antartica]

Originally Posted by pwarren

So I thought that instead of trying to find every instance of things that needed porting there, I'd try and use a mixed approach, use xepdmgr for the menu button dialogues, and the erdm style for page flipping.

To my questions then

Is that pretty much what the EPDCancel() function is for?
and
How do I use that in FBReader? (or other code for that matter)

Well, really it's EpdRefreshAuto() the one that enables/disables the autorefresh.

See post 98 in this thread:

https://www.mobileread.com/forums/sho...5&postcount=98

That code sample is what you are looking for, if I'm not mistaken: when you want to refresh the main viewing area of FBReader, disable xepdmgr (with "EpdRefreshAuto(Epd,0)"), then do the update and refresh manually (using either "EpdRefreshFull(Epd)" or the functions in erdm -- I think that here there should be no difference in elapsed time between these functions) and then re-enable the auto-refresh (with "EpdCancel(Epd),EpdRefreshAuto(Epd,1)".

[pwarren]

Ah Ok, that makes sense, thanks Antarctica!

What I meant by using it in the code is, do I have to #include and link in something?


And, I've actually done proper timing tests for various books on both versions of FBReader, with xepdmgr, and using erdm.

average of 10 page forward, page backward turns, on the same epub file.
erdm: 4.78s
xepd: 6.22s

So, the improvements aren't as dramatic as I'd thought, but based on a bit of use, nearly 5 seconds seems to be much more manageable than just over 6 seconds.

and wow, 2 seconds is blindingly fast, I hadn't used ipdf much, most of my ebooks have been epub or mobipocket format, but that is just amazing.

[Antartica]

Originally Posted by pwarren

What I meant by using it in the code is, do I have to #include and link in something?

Yes, you have to include the xepdmgrclient.h file and link with the xepdmgrclient.c compiled to .o .

The quick and dirty version is to include the xepdmgrclient.c in you program and you dont have to link anything.