Sony reveals prototype 13.3-inch e-ink slate with stylus

[Sil_liS]

Originally Posted by HarryT

If by "better" you mean "faster", in a portable device it's always a compromise between CPU speed and power consumption. A faster CPU means higher power consumption and a shorter battery life, or a larger battery and a heavier device.

I'm not sure that a faster CPU is even necessary for an eink device.

[HarryT]

Originally Posted by Sil_liS

I'm not sure that a faster CPU is even necessary for an eink device.

Rendering a complex PDF file does take a great deal of computational power, so there's certainly more reason to have a fast CPU on a device designed to read PDF than one aimed at ePub or Kindle formats. I'm sure, though, that Sony's engineers will have used a CPU that's appropriate for the task that the device is designed to carry out.

[Salgueiros]

A good CPU is definitely necessary for a e-ink device of this type. I have been trying to read large PDF's in the Kindle DX, and, in the cases where the file has figures or photos, the device freezes frequently. And when it does not, it gets incredibly slow.

So good CPU, but not too good (for the sake of battery life) is what i expect in this device.

I can't wait to have one of these.

[markom]

Originally Posted by Salgueiros

A good CPU is definitely necessary for a e-ink device of this type. I have been trying to read large PDF's in the Kindle DX, and, in the cases where the file has figures or photos, the device freezes frequently. And when it does not, it gets incredibly slow.

So good CPU, but not too good (for the sake of battery life) is what i expect in this device.

I can't wait to have one of these.

For Kindle DX it is really indispensable to install kindlepdfviewer thereon, if we want a good pdf reader, fast enough, with all necessary zooming options, pdf txt underscoring, gamma correction etc.

https://www.mobileread.com/forums/sho...d.php?t=157047

If some pdfs use complex compression method or very big pages that will make even tablets like iPad show&turn pdf pages really slow, we can use k2pdfopt app to optimize pdf for Kindle DX or DPT-S1 beforehand and page rendering&turning will be normal again.

http://www.willus.com/k2pdfopt/

[Sil_liS]

Originally Posted by HarryT

Rendering a complex PDF file does take a great deal of computational power, so there's certainly more reason to have a fast CPU on a device designed to read PDF than one aimed at ePub or Kindle formats. I'm sure, though, that Sony's engineers will have used a CPU that's appropriate for the task that the device is designed to carry out.

Wouldn't it be better to increase the number of cores?

[HarryT]

Originally Posted by Sil_liS

Wouldn't it be better to increase the number of cores?

Not being a hardware designer, I honestly couldn't say which would be better. I'm sure that Sony's engineers know much more about it than I do, and will have made the appropriate choice of CPU.

[rkomar]

Originally Posted by Sil_liS

Wouldn't it be better to increase the number of cores?

The program would have to be able to use the cores in parallel. I don't know if the PDF rendering code is written that way. I would guess not as I think the PDF language requires a state machine to process (and is thus hard and inefficient to implement multithreaded), but I could be wrong.

Also, more computing power means more battery power required. The engineers are always trying to find that sweet spot between system power and battery life that will please most people.

[Sil_liS]

Originally Posted by rkomar

The program would have to be able to use the cores in parallel. I don't know if the PDF rendering code is written that way. I would guess not as I think the PDF language requires a state machine to process (and is thus hard and inefficient to implement multithreaded), but I could be wrong.

Also, more computing power means more battery power required. The engineers are always trying to find that sweet spot between system power and battery life that will please most people.

Yes, but isn't the advantage of multiple cores that you don't have to use all of them? So if you have a simple pdf you could use less power and if you have a complex one you could still open it at an agreeable speed.

[FantoM]

Originally Posted by HarryT

This question has been answered earlier in the thread.

Yes, my bad, I even read it and commented when it was posted lol...

[rkomar]

Originally Posted by Sil_liS

Yes, but isn't the advantage of multiple cores that you don't have to use all of them? So if you have a simple pdf you could use less power and if you have a complex one you could still open it at an agreeable speed.

That would be true for tasks that can use multiple cores at once, but as I said earlier, I kind of doubt that rendering PDF pages is such a task. PDFs are not just made up of data like an image or an HTML page is. The PDF contents are really programs meant for a state engine, i.e. each instruction is executed a certain way that depends on the current state of rendering at that moment. For example, the instruction may be to draw a line from point A to point B. How the line is drawn (thickness, foreground colour, background colour, line style, corner style,...) depends on the engine state. The bits of state can be changed at any time during the rendering of a page, so the only way to know that the state is correct when you get to a certain instruction is to start from one of the set points where the state is known (usually the beginning of a page) and work through all the instructions from there to the current point. There is also no way that CPU 1 can work on the first half of the page while CPU 2 works on the second half, because CPU2 won't know what state to start from until CPU1 is done. There might be instructions that can somehow be farmed out to multiple CPUs (I don't really know), but I don't expect there are that many of those.

That said, two CPUs can work on two separate pages without interfering with each other. That doubles the RAM requirements, though.

Perhaps modern PDF versions break up the pages into separate "programs" that can be individually rendered. It's been over a decade since I did any programming on PDF renderers, and things may have changed since then. If so, multiple CPUs could be used to render a PDF page, but it would depend on the version of PDF that the document is stored in. Older versions would still only work with one CPU per page, no matter how complex.

[Sil_liS]

Originally Posted by rkomar

That would be true for tasks that can use multiple cores at once, but as I said earlier, I kind of doubt that rendering PDF pages is such a task. PDFs are not just made up of data like an image or an HTML page is. The PDF contents are really programs meant for a state engine, i.e. each instruction is executed a certain way that depends on the current state of rendering at that moment. For example, the instruction may be to draw a line from point A to point B. How the line is drawn (thickness, foreground colour, background colour, line style, corner style,...) depends on the engine state. The bits of state can be changed at any time during the rendering of a page, so the only way to know that the state is correct when you get to a certain instruction is to start from one of the set points where the state is known (usually the beginning of a page) and work through all the instructions from there to the current point. There is also no way that CPU 1 can work on the first half of the page while CPU 2 works on the second half, because CPU2 won't know what state to start from until CPU1 is done. There might be instructions that can somehow be farmed out to multiple CPUs (I don't really know), but I don't expect there are that many of those.

That said, two CPUs can work on two separate pages without interfering with each other. That doubles the RAM requirements, though.

Perhaps modern PDF versions break up the pages into separate "programs" that can be individually rendered. It's been over a decade since I did any programming on PDF renderers, and things may have changed since then. If so, multiple CPUs could be used to render a PDF page, but it would depend on the version of PDF that the document is stored in. Older versions would still only work with one CPU per page, no matter how complex.

Different CPUs for different pages makes the most sense. RAM is cheap and is one of the specs that people would look at (even those that don't know what it represents).

[DaleDe]

Originally Posted by Sil_liS

Different CPUs for different pages makes the most sense. RAM is cheap and is one of the specs that people would look at (even those that don't know what it represents).

With E Ink the second page is pre-staged while the first page is still displayed. No refresh so no need to tie up the processor or memory. You might use a second cpu for running a annotation tool or some other independent task but you are not likely to need a PDF viewer divided by pages.

Dale

[user743]

the "pen" holder makes it twice as thick (see left picture). hopefully it will be fixed.

[Kumabjorn]

I think the pen holder is like a rubber band so it doesn't make the device twice as thick.

[user743]

fine. so the pen makes it twice as thick, when it's in it's holder.