| 01:10.28 | *** join/#card10badge DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 01:18.25 | *** join/#card10badge ebi_ (~quassel@dynamic-077-007-029-128.77.7.pool.telefonica.de) |
| 01:19.26 | *** join/#card10badge mkie (~quassel@dynamic-077-007-029-128.77.7.pool.telefonica.de) |
| 02:12.17 | *** join/#card10badge erlehmann (~erlehmann@dynamic-046-114-037-150.46.114.pool.telefonica.de) |
| 03:57.31 | *** join/#card10badge jrt (~jrt@dynamic-078-055-093-234.78.55.pool.telefonica.de) |
| 05:37.26 | *** join/#card10badge DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 08:26.27 | *** join/#card10badge mmu_man (~revol@82-65-227-82.subs.proxad.net) |
| 08:27.26 | *** join/#card10badge jrt_ber (~jrt@vm-irc.spline.inf.fu-berlin.de) |
| 08:31.03 | *** join/#card10badge jrt (~jrt@dynamic-078-055-093-234.78.55.pool.telefonica.de) |
| 08:40.14 | *** join/#card10badge jrt (~jrt@dynamic-078-055-093-234.78.55.pool.telefonica.de) |
| 09:15.25 | *** join/#card10badge DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 09:35.42 | *** join/#card10badge theAntimon (~matze@p5b313488.dip0.t-ipconnect.de) |
| 09:36.08 | *** part/#card10badge theAntimon (~matze@p5b313488.dip0.t-ipconnect.de) |
| 09:59.16 | *** join/#card10badge Viech (~Viech@viech.name) |
| 09:59.17 | *** join/#card10badge Viech (~Viech@unvanquished/developer/viech) |
| 10:31.57 | *** join/#card10badge oida (~oida@gateway/tor-sasl/oida) |
| 10:49.55 | *** join/#card10badge Viech (~Viech@viech.name) |
| 11:46.34 | *** join/#card10badge theAntimon (~matze@p5b313488.dip0.t-ipconnect.de) |
| 12:05.14 | *** join/#card10badge msvb-lab (~msvb-lab@monero/hardware/michael) |
| 12:30.25 | *** part/#card10badge theAntimon (~matze@p5b313488.dip0.t-ipconnect.de) |
| 13:22.52 | *** join/#card10badge thor77 (~thor77@web01.crapwa.re) |
| 13:28.56 | *** join/#card10badge erlehmann (~erlehmann@dynamic-046-114-037-006.46.114.pool.telefonica.de) |
| 14:15.15 | *** join/#card10badge erlehmann (~erlehmann@dynamic-046-114-034-010.46.114.pool.telefonica.de) |
| 16:00.40 | *** join/#card10badge msvb-lab (~msvb-lab@monero/hardware/michael) |
| 16:49.53 | *** join/#card10badge theAntimon (~matze@p5b313488.dip0.t-ipconnect.de) |
| 16:49.56 | *** part/#card10badge theAntimon (~matze@p5b313488.dip0.t-ipconnect.de) |
| 17:19.56 | schneider | more spoilers: https://web.xtort.eu/~dump/g-watch-ancs.mp4 |
| 17:20.08 | schneider | it's even reading a PNG from flash do display the icon :) |
| 17:43.48 | Rahix | ooh, that's cool! |
| 17:44.37 | Rahix | how does the interruption of the running app work (if that is what is happening at all)? |
| 17:51.05 | schneider | it is not interrupted. i implemented support for notifications into g-watch |
| 17:51.53 | schneider | but you are right: in theory epicardium could provide such a functionality |
| 17:52.58 | Rahix | I was thinking about such a design in the past... |
| 17:53.29 | sknebel | cool! |
| 17:54.09 | Rahix | I'd want to add a few things along side it: |
| 17:54.14 | Rahix | - Apps should have some sort of in-memory state which they can "store" in epicardium across invocation of other applications |
| 17:54.45 | Rahix | - There should be a hook in an app which runs before it is forcibly stopped, to serialize some state into this semi-persistent storage (or even onto flash) |
| 17:55.39 | schneider | yes, thought the same before going to bed yesterday. this feature would match well here |
| 17:56.17 | Rahix | we could then also extend the "alarm" API to schedule an application waking up again in the future, e.g. a calendar setting a reminder |
| 18:15.33 | schneider | btw: this happened while we were working on card10: https://blog.lvgl.io/2019-02-20/micropython-bindings |
| 18:19.22 | schneider | it apparently also has support for various file formats https://github.com/lvgl/lv_binding_micropython/blob/master/lib/imagetools.py |
| 18:21.06 | schneider | (ok, png) |
| 18:40.17 | *** join/#card10badge oida (~oida@gateway/tor-sasl/oida) |
| 18:49.23 | *** join/#card10badge theAntimon (~matze@p5b313488.dip0.t-ipconnect.de) |
| 18:49.28 | *** part/#card10badge theAntimon (~matze@p5b313488.dip0.t-ipconnect.de) |
| 20:05.54 | schneider | oh, i got that lodepng python binding to compile |
| 20:08.57 | pippin | I think I have built 3 different PNG loaders on the card10, no longer recall which one had lowest RAM overhead :) |
| 20:09.11 | schneider | ;) |
| 20:11.39 | pippin | and in the end, stb_image was the real winner for me,. for GIF, since it can deal with larger than RAM files. |
| 20:18.31 | pippin | Rahix: the performance of the "ctx desktop" now seem to have improved 2-3x, with the fixing of the shape-cache that speeds up text https://ctx.graphics/caching-and-threading/ |
| 20:21.13 | pippin | Configured with a smaller size threshold for doing the caching makes it applicable also on mcu's - but it eats RAM - and perhaps only makes sense if well integrated with "texture" memory for generic use. |
| 20:32.00 | schneider | so, what taked lodepng 50 ms takes png.py 1500 ms |
| 20:32.04 | schneider | takes |
| 20:33.06 | schneider | something i noticed: both libraries return RGBA arrays. we might want to accommodate that in the display.blit function |
| 20:34.08 | schneider | that would make it possible to easily blit PNG files with transparencies to the display |
| 22:12.15 | *** join/#card10badge Viech (~Viech@new.viech.name) |
| 22:12.15 | *** join/#card10badge Viech (~Viech@unvanquished/developer/viech) |
| 22:41.44 | *** join/#card10badge msvb-lab (~msvb-lab@monero/hardware/michael) |