View Single Post
Old 03-21-2012, 09:00 PM   #38
geekmaster
Carpe diem, c'est la vie.
geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.
 
geekmaster's Avatar
 
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
Quote:
Originally Posted by kaminkatze View Post
Yeah, but with arrays vs. starting a (series of) new process(es) for every pixel access, this might be one of the rare cases. Maybe I do a pure sh version with smaller grid, if I'm lucky enough to find a good solution. Definitely keeping my eyes open.



For today only the linear array style. Thus no wrap around on top/bottom.
It initializes the array with the thresholded framebuffer content.
You could try keeping the entire framebuffer in a string, and write it to the framebuffer in one large chunk.

But we *are* getting into areas where after prototyping a proof-of-concept in shell script, better performance may require a compiled language. But then again, the eink display is the limiting factor, so perhaps we can make faster shell scripts...

Part of the reason for doing this in /bin/sh is to get people involved who may not be ready for a compiled language, and to prove that we CAN do more than we think even with very primitive tools.
geekmaster is offline   Reply With Quote