iLiad Introducing the new Sony-Reader-speed ipdf

[R2D2]

Irex would have to pay for it. But in my opinion it would be worth it, because it is a very advanced piece of software which solves some of the current problems and which would free some development resources for tasks, which are more important than imperfectly reinventing the wheel (that's a gross exageration, I know, but it helps to understand my point).

So let's invest money into an iLiad Picsel Browser and concentrate on other things.

[CommanderROR]

It might be worth a try. Will you post it at the iRex Forums? I think it would be better to have it there than in Scotty's PDF viewer thread...:-)

[R2D2]

Ok, put it on the IREX forum. But I am sure that even with Picsel Browser installed there would be enough things left for Scotty to be improved. ;-)

[vranghel]

Wow! That browser is truly impressing. I really wish that something like that will be implemented into our iLiad. It would make reading so much more enjoyable/easier.

Now the question is if irex would be willing to purchase licenses (or some sort of agreement) for this browser. That means some extra money coming from who?
Probably those of us who want to use it.

[R2D2]

Well, development does cost money as well. It would be a radical approach, but it would probably make sense, even economically.

[scotty1024]

Motorola bundles Picsel on the Motorola Ming (a1200) cellphone (my wife and I both have one.)

Motorola opts to use Opera as their web browser on the phone, 'nuff said there.

I'e found the tool useful for pulling up a document for reference purposes but using it as a reader has always been too tedious.

It would also require some non-trivial customizing to fit into iRex's plumbing, all of which I'm sure Picsel would be more than happy to do per hour for $$$. And of course anytime iRex wanted to change anything, I'm sure Picsel would be more than happy to do it per hour for $$$. And if Picsel had any bugs in their code I'm sure they'd be happy to fix those per hour for $$$ as well.

[R2D2]

Originally Posted by scotty1024

Motorola bundles Picsel on the Motorola Ming (a1200) cellphone (my wife and I both have one.)

Motorola opts to use Opera as their web browser on the phone, 'nuff said there.

It works perfectly well to view HTML pages. Of course Opera offers more options for real web-browsing. But to view HTML I prefer the Picsel Browser.

Of course using it on the iLiad will cost money. You can probably ask Sharp how much it does.

On the Zarus people use QPDF, a very nice programm. But people did nevertheless send heaps of money (135 Euro) to Japan to get the Picsel Browser. Nuff said?

Rendering speed alone would be enough reason for me to make a call to Picsel Technologies. Take a look at the video.

Of course an alternative would be to find out what is going on behind the scenes of the Picsel Browser and then try to rewrite XPDF and all the other viewers. IMHO the other way around of supplying reader for DRM and so on for a Picsel Browser seems to be much more promising for me. Because at the end of the day I need a perfect software for a perfect hardware and not just a perfect hardware.

[scotty1024]

Originally Posted by R2D2

Rendering speed alone would be enough reason for me to make a call to Picsel Technologies. Take a look at the video.

Of course an alternative would be to find out what is going on behind the scenes of the Picsel Browser and then try to rewrite XPDF and all the other viewers. IMHO the other way around of supplying reader for DRM and so on for a Picsel Browser seems to be much more promising for me. Because at the end of the day I need a perfect software for a perfect hardware and not just a perfect hardware.

Technically the iLiad isn't using xpdf, its using poppler with an iRex supplied front end. I've got a couple more speed ups for the iRex code that affect actual drawing to the screen time that will shave a bit off the throwing up the raster time.

But at this point, after converting to 8 bit grey with no ED, we're rapidly reaching the point of diminishing returns vs the e-Ink panel update overhead. They really did do a good job on their threaded rendering engine (other than not planning for re-use). Running 8 bit lean like it is now I have a hard time out pacing it.

[scotty1024]

OK, here is the rev 4 of ipdf.

The major enhancement here is using shared memory to pass the image from ipdf to the X server instead of shoving it down the Xlib pipe to the X server.

I also removed the fill rectangle code and handled its function in the code that transfers the Splash bitmap to the shared memory buffer. The shared memory buffer is a full sized CLIENT_AREA buffer. If the Splash bitmap is too narrow and/or too short I fill the unused areas in the buffer with white bytes (rather than fill the whole client area with white, then paint in the bitmap.)

Just that extra bit quicker now, you can see it, but you can't describe it, but you know you want it.

Enjoy.

[tribble]

Scotty, you are making me cry

I want to see it. Can you make a short vid?

Oh, and are ou planning to try and implement that dithering, that matthijs mentioned? Then we might all get to enjoy your improvements with the next update.

[scotty1024]

iRex and I have been having a very cordial email exchange back and forth on several topics.

They've explained why images must look good in PDF now and I fully support their business needs in that department. We're discussing how I could best assist them in modifying Poppler.

In the mean time I'm polishing what I have as best as I can.

Sources will be in the project's area here on MR later tonight.

[scotty1024]

In case anyone was wondering "Is shared memory really a good thing for sending bitmaps to the X server?"

I thought I'd share this comparative pair of traces.

This is the new ipdf rev 4 sending the bitmap to X. Writes 44 bytes, gets two 32 byte responses.

write(22, "\201\3\n\0\26\0\340\0%\0\340\0\0\3\247\3\0\0\0\0\0\3\247"..., 44) = 44
read(22, "\203u\226\0z\17>\2408\0\0\0\25\0\340\0\0\0\0\0\1\0\1\0"..., 32) = 32
read(22, "\1\1\230\0\0\0\0\0\25\0\340\0\234\325\1\0t:\r\0h:\r\0\274"..., 32) = 32

This is the 2.7 ipdf sending the bitmap to X. Those resource unavailable's are the X server telling the client "back off man the fire hose is choking me!"

You'll also notice it starts by trying to write 261888 bytes but X only accepts 65280 bytes due to a limit in the socket buffer size.

writev(22, [{"8\1\4\0 \0\340\0\4\0\0\0\377\377\377\0F\0\5\0\26\0\340"..., 60}, {"\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 261888}], 2) = 65280
writev(22, [{"\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 196668}], 1) = 65280
writev(22, [{"\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 131388}], 1) = 65280
writev(22, [{"\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 66108}], 1) = 65280
writev(22, [{"\0\0\0\0\0?\277\377\377\377\377\377\377\377\377\377\377"..., 828}], 1) = 828
writev(22, [{"H\2\306\377\26\0\340\0 \0\340\0\0\3U\1\0\0X\1\0\10\340"..., 24}, {"\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 261888}], 2) = 65280
writev(22, [{"\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 196632}], 1) = 65280
writev(22, [{"\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 131352}], 1) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=22, events=POLLIN|POLLOUT, revents=POLLIN}], 1, -1) = 1
ioctl(22, FIONREAD, [32])               = 0
read(22, "\203u\n\1i\230G\2408\0\0\0\25\0\340\0\0\0\0\0\1\0\1\0\1"..., 32) = 32
poll([{fd=22, events=POLLIN|POLLOUT, revents=POLLOUT}], 1, -1) = 1
writev(22, [{"\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 131352}], 1) = 65280
writev(22, [{"\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 66072}], 1) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=22, events=POLLIN|POLLOUT, revents=POLLOUT}], 1, -1) = 1
writev(22, [{"\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 66072}], 1) = 65280
writev(22, [{"\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 792}], 1) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=22, events=POLLIN|POLLOUT, revents=POLLOUT}], 1, -1) = 1
writev(22, [{"\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 792}], 1) = 792
writev(22, [{"H\2F\271\26\0\340\0 \0\340\0\0\3\367\0\0\0\255\2\0\10\340"..., 24}, {"\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 189696}], 2) = 65280
writev(22, [{"\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 124440}], 1) = 65280
writev(22, [{"\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 59160}], 1) = 59160
write(22, "8\2\4\0 \0\340\0\4\0\0\0\0\0\0\0C\0\5\0\26\0\340\0 \0\340"..., 40) = 40
read(22, 0xbffff77c, 32)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=22, events=POLLIN, revents=POLLIN}], 1, -1) = 1
read(22, "\1\1\22\1\0\0\0\0\25\0\340\0@\353\1\0t:\r\0h:\r\0\2749"..., 32) = 32

That's about as night and day as "This is your brain, this is your brain on drugs."

[NatCh]

This is your iLiad, and this is your iLiad on downers?

[scotty1024]

Originally Posted by tribble

I want to see it. Can you make a short vid?

Well no vid but I did figure out how to do screen captures and posted some over in the idjvu thread (I spaced making a new thread, sigh).

[arivero]

I was looking at the sources of ipdf, mainly to see where did they patch the /Launch hole. Man they have needed to reorder everything to translate xpdf to ipdf !? Or is there a g++ version of xpdf already around?

I now approve the idea of building idjvu over ipdf, if only to use the effort of going object oriented.