iLiad xepdmgr algorithms dicussion thread

[Antartica]

Hi! Hansel suggested opening another thread for discussing improvements to the algorithms used in xepdmgr for handling the Typing refresh and the combining of rectangles, so here it is.

Right now (xepdmgr 1.0), the daemon just counts the number of pixels in the area to update and depending on whether it's less than a threshold or not (the threshold is #define'd as 1/3 of the iliad screen), it uses the typing refresh or the full refresh.

About the timeout, it waits 0.5seconds from the last update to commit it to the screen (if there is another change while waiting, it resets the timeout and waits 0.5s again).

Any ideas to improve this?

[hansel]

Some Ideas

• do not merge small dirty rectangles that are far apart (example: pressing '=' on a calculator updates the '=' button (down, right) and the displayed value (up, left). Resulting in a very big rectangle ==> unneeded 'full' update. Same thing might happen on diagonal mouse moves...
• do a full update once in a while (say once every 50 'typing' updates), even if there is no big dirty rectangle. This avoids slowly degrading display quality

PS: any idea how and where the cpu throttling is done? (I didn't find the sources yet). Might be a good option to throttle when there are no display changes for a few seconds...

Continue the good work!
Hansel.

[Antartica]

Originally Posted by hansel

do not merge small dirty rectangles that are far apart (example: pressing '=' on a calculator updates the '=' button (down, right) and the displayed value (up, left). Resulting in a very big rectangle ==> unneeded 'full' update. Same thing might happen on diagonal mouse moves...

Done in version 1.2 . Please, check that the issue is fixed ;-)

[Adam B.]

Originally Posted by hansel

PS: any idea how and where the cpu throttling is done? (I didn't find the sources yet). Might be a good option to throttle when there are no display changes for a few seconds...

I believe CPU Throttling is done by the powerMgr application. Sources haven't been released for it.

[hansel]

Originally Posted by Adam B.

I believe CPU Throttling is done by the powerMgr application. Sources haven't been released for it.

I was thinking about stuff in liberipc:

/**
 * Put cpu in idle mode
 * args: MHz: the desired cpu clock
 *       timeout: the number of seconds to wait before changing the cpu mode
 */
int pwrGotoIdleMode(erClientChannel_t channel, int MHz, int timeout);

Any idea how to check the current cpu mode / speed? I hope that the cpu is not slowed down when we switch the busu led off...

[hansel]

Antartica (and All)

I thought some more about the rectangle merging... it's not very useful unless we are able to do partial screen updates. On the other hand it might be relevant to know how many times a given area has been changed (might get uglier and uglier)

An alternative (and simple) approach might be:
- divide the screen in blocks (say 10x10 or 20x20)
- when we get dirty rectangle events: increment the dirty flag off the corresponding blocks
- when the timer expires: do a Typing or Full refresh depending on the sum of the dirty flags. Typing if the total dirty count has changes since last time (continue counting), Full if it exceeds a certain limit (then: reset it).

What do you think?

[Antartica]

Originally Posted by hansel

What do you think?

Well, the code to merge rectangles is already done and is not computationally intensive.Even if its only benefit is to select between full and typing refresh more reasonably, I think that it worths its complexity increase .

OTOH, counting "how dirty" is an area could be interesting. I'm already calculating intersections, so it would be a matter of having running sum of the intersections occurred in every tracked area (and when merging tracked areas, sum them). If the ratio intersected pixels/area is higher than some number, do a full refresh. The only problem with this approach is that right now we're discarding the tracked areas info after the typing refresh.

It can be reasonable saving the info for nnnxnnn blocks as you say. Time to think about it.

About partial screen updates: I still have faith that we will get to that point sometime ;-). At least to support scribbles...

[hansel]

Originally Posted by Antartica

About partial screen updates: I still have faith that we will get to that point sometime ;-). At least to support scribbles...

It might just be less 'not implemented' as the include files suggest Any concrete ideas?

hel@xyzzy:~$ strings /usr/local/lib/liberdm.a
[...]
(E)erdmServer.c:%d,%s() Trying to do a partial update of a line (%d,%d):(%d,%d)
[...]

[hansel]

Originally Posted by hansel

Antartica (and All)An alternative (and simple) approach might be:
- divide the screen in blocks (say 10x10 or 20x20)
- when we get dirty rectangle events: increment the dirty flag off the corresponding blocks
- when the timer expires: do a Typing or Full refresh depending on the sum of the dirty flags. Typing if the total dirty count has changes since last time (continue counting), Full if it exceeds a certain limit (then: reset it).
What do you think?

I implemented this: t works and the code is simple... It's a bit hard to integrate this as option in the existing xepdmgr, so I had to strip it... If somebody wants to play with it I can PM it...

[Antartica]

Originally Posted by hansel

I implemented this: t works and the code is simple... It's a bit hard to integrate this as option in the existing xepdmgr, so I had to strip it... If somebody wants to play with it I can PM it...

If it works better than the tracked areas route, there's nothing bad in scrapping the tracked_areas part and using this.

In reality, the only thing we should not scrap is saving the information of the dirty rectangle, so as if we can do partial updates, have the info for it (in theory the bottleneck with updates is in the transmission of data to the delta chip***; if the area is smaller, the update should be able to be done faster).

*** if I have understood right iRex's explanations of the improvements to the delta chip in the DR1000.

[hansel]

Hi Antartica,

Any news?

Originally Posted by Antartica

About partial screen updates: I still have faith that we will get to that point sometime ;-). At least to support scribbles...

Removing the '-p' option when starting displayMgr (in start.sh) should enable partial updates :-) See displayMgr/displayMgr.c:218

The execution of the partial update starts at displayMgr/displayMgr.c:625

PS: they even merge rectangles at displayMgr/displayMgr.c:480

[Antartica]

Originally Posted by hansel

Any news?

Unfortunately not. i've not had spare time to devote for the iliad lately :-(.

I've just downloaded the irex's second batch of sources and right now I'm with the delta driver.

With the other batch I just chased a wrong path; I was reading liberscribble, but it uses the brush functions of the delta driver instead of pushing pixels to it . Not what I needed. Amazingly the delta driver does a lot of things I supposed would be handled in userspace :-o... didn't expect that .

Originally Posted by hansel

Removing the '-p' option when starting displayMgr (in start.sh) should enable partial updates :-) See displayMgr/displayMgr.c:218

The execution of the partial update starts at displayMgr/displayMgr.c:625

PS: they even merge rectangles at displayMgr/displayMgr.c:480

Ok, I'll look at it too . Thanks :-b

[Antartica]

Originally Posted by hansel

Removing the '-p' option when starting displayMgr (in start.sh) should enable partial updates :-) See displayMgr/displayMgr.c:218

Have just looked at it. Easy code .Conclusion: I could put the ioctl directly in xpedmgr, but they surely had a reason t had it disabled in irex sources; before inclusing this in xepdmgr I'll look at pageBar (also does a partial update) to see how they've done it there. Correction: will have to look lsewere; pageBar uses full screen updates...

Thanks .

[hansel]

I think the partial update stuff is fairly new. We should test it with a small program to see if it works, how it looks on the display, and how it performs...

Idea:

Maybe the most universal solution would be to integrate the xdamage stuff in displayMgr (make a replacement with the same name, but with extra features)

• When starting displayMgr -x: your code (dedicated thread) handles the display updates directly, and disables al 'normal' updates
• when starting displayMgr in the normal way, your code is not invoked (100% compatible).

What do you think?

[Antartica]

Originally Posted by hansel

I think the partial update stuff is fairly new. We should test it with a small program to see if it works, how it looks on the display, and how it performs...

Agreed :-).

Originally Posted by hansel

Idea:

Maybe the most universal solution would be to integrate the xdamage stuff in displayMgr (make a replacement with the same name, but with extra features)

• When starting displayMgr -x: your code (dedicated thread) handles the display updates directly, and disables al 'normal' updates
• when starting displayMgr in the normal way, your code is not invoked (100% compatible).

What do you think?

Idea taken .

The plan was to support the displayMgr protocol in xepdmgr anyway, merging the two will fulfill that neatly. I was intending to reimplement it, but after all there is no need for it (displayMgr is GPL ). Maybe I was having some NIH syndrome.

Notes:

1. Will integrate displayMgr code inside xepdmgr, as I want to keep the current main loop. But will honour displayMgr command-line as used by irex scripts.

2. No threads; personally I think that they don't worth the effort when in UNIX; too many things are non-reentrant. If needed I'll create a child process, but it doesn't look that it's needed.

Hope I have some time for it this week.