MobileRead Forums - View Single Post

scotty1024 · 10-31-2006, 11:12 PM

Can we take a deep breath and then let it out slowly here?

Power will get better. I've read the PXA-255 CPU manual, I've poked and prodded. I'm not worried as I see so many things to change for the better its like being a kid in toy store with Daddy's Black Amex Card.

The code base is very fat and bloated and much can still be done at the application layer.

Today I've removed nearly all the X server code from ipdf. It now writes directly to the frame buffer and bench marks show that I'm consistently decreasing memory foot print and CPU usage as I pare down the code.

Poppler is next. As I put in the iRex required error distribution routine(s) I'll code them, as well as the zooming logic, using the PXA-255 CPU's MMX opcodes to increase their efficiency.

In addition, right now benchmarks in ipdf show it takes Poppler 1.5 seconds to 2.6 seconds to draw a single page of just text (like say my Baen RTF encoded as PDF 1635: Canon Law). That is an outrageous amount of time and thus I know there is something just waiting to be optimized in the text rendering logic. Ditto my Jack Rabbit Performance Test, a simple CCITT 2D encoded bitmap takes 30 seconds to decode on a 32 bit 400MHz PXA-255? I don't think so! A frickin' FAX machine running an 8 bit CPU at 16MHz can do it faster than that!

Things are going to get better.

Just remember, iRex didn't write Poppler. And the Poppler writers didn't write it for a hand held. Nothing personal in all this, it just needs to be re-worked for the new reality it finds itself in.

We need to encourage iRex to continue collaboration and let us knock off a few things that are higher on our priority list than they are on iRex's so iRex is free to spend more resources on their B2B priorities.

10-31-2006, 11:12 PM	#33
scotty1024 Banned Posts: 1,300 Karma: 1479 Join Date: Jul 2006 Location: Peoples Republic of Washington Device: Reader / iPhone / Librie / Kindle	Can we take a deep breath and then let it out slowly here? Power will get better. I've read the PXA-255 CPU manual, I've poked and prodded. I'm not worried as I see so many things to change for the better its like being a kid in toy store with Daddy's Black Amex Card. The code base is very fat and bloated and much can still be done at the application layer. Today I've removed nearly all the X server code from ipdf. It now writes directly to the frame buffer and bench marks show that I'm consistently decreasing memory foot print and CPU usage as I pare down the code. Poppler is next. As I put in the iRex required error distribution routine(s) I'll code them, as well as the zooming logic, using the PXA-255 CPU's MMX opcodes to increase their efficiency. In addition, right now benchmarks in ipdf show it takes Poppler 1.5 seconds to 2.6 seconds to draw a single page of just text (like say my Baen RTF encoded as PDF 1635: Canon Law). That is an outrageous amount of time and thus I know there is something just waiting to be optimized in the text rendering logic. Ditto my Jack Rabbit Performance Test, a simple CCITT 2D encoded bitmap takes 30 seconds to decode on a 32 bit 400MHz PXA-255? I don't think so! A frickin' FAX machine running an 8 bit CPU at 16MHz can do it faster than that! Things are going to get better. Just remember, iRex didn't write Poppler. And the Poppler writers didn't write it for a hand held. Nothing personal in all this, it just needs to be re-worked for the new reality it finds itself in. We need to encourage iRex to continue collaboration and let us knock off a few things that are higher on our priority list than they are on iRex's so iRex is free to spend more resources on their B2B priorities.