Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2021-11-02

00:35:16 Join akaWolf [0] (
01:46:02 Quit pixelma (Quit: .)
01:46:02 Quit amiconn (Quit: - Chat comfortably. Anywhere.)
01:48:33 Join amiconn [0] (
01:48:33 Join pixelma [0] (
01:54:39***Saving seen data "./dancer.seen"
03:54:40***No seen item changed, no save performed.
04:12:45 Nick funman_ is now known as funman (
05:43:35 Quit wolfshappen (Ping timeout: 260 seconds)
05:43:43 Join wolfshappen_ [0] (
05:54:41***Saving seen data "./dancer.seen"
06:14:22Arsengood news friends:
06:14:32Arsenif you're using beets, it'll now make covers work on rockbox
06:14:38Arsen(or rather, have the option to)
06:14:44Arsenon that note, rockbox doesn't do PNG, right?
06:18:44gevaertsI think so. It's been a while since I looked...
06:45:46speachycorrect. nobody's written a row-based decoder yet.
06:54:35Arsenis that even possible for PNG?
06:54:48ArsenI haven't looked into the format before, or any image format other than gif really
06:58:01speachyIIRC PNG uses standard zlib to compress the byte stream. so you need to have sufficient RAM to deal with whatever the decompression window happens to be.
06:59:03speachyI want to say you'll need a minimum of 64K of buffer, plus more for the decompressor state (eg huffman tables)
07:00:46Arsenthat doesn't sound impossible, though I've never implemented either zlib nor png before
07:00:48speachywhereas jpg works using 8x8 blocks. you don't technically need more than one row of history, though it'll be a lot faster if you do 8 rows at a time.
07:01:19speachyok, png uses deflate/inflate, with a window of 32K
07:01:48speachy(well, "of at most 32768 bytes"
07:04:30speachyit's not impossible but would effectively require a completely independent libpng-api-incompatible decoder implementation.
07:05:39Arsenwell, yeah, that's to be expected, right?
07:13:19speachylooks like someone might have done it for us already. 48K RAM required.
07:14:32speachyline-by-line decoding using a callback.
07:19:48speachythis didnt' exist the last time I looked
07:53:07Arsenooh, nice
07:53:56ArsenI imagine you might want to modify it somewhat to use an existing zlib implementation, if one exists?
07:54:05Arsen(in rockbox that is)
07:54:44***No seen item changed, no save performed.
07:58:13sporkimageviewer plugin already decodes png's
07:59:26sporkbased on
08:14:03braewoodsArsen: the regular png library has an API for decoding one row of pixels at a time.
08:14:09braewoodsbeyond that I don't know anything
08:17:17braewoodsArsen: fyi we already have a zlib alternative in core. my inflate code. only does decompression.
08:17:30Arsenyeah, I expected that
08:17:39Arsenthat's why I asked
08:17:56braewoodsit was intended for ZIP files but can be used for png data
08:19:11braewoodsit's faster and a bit bulkier than tinf but it's a good balance for the code size i think
08:19:44braewoodsstill slower than zlib but not nearly as fat
08:32:17braewoodsArsen: it's compatible with all 3 main types of deflate streams. let me know if you want to use it though iirc it's not available to plugins last i checked.
08:32:29braewoodsnot hard to add support though
08:32:36braewoodsthe api was kept fairly simple
08:32:42Arsenbraewoods: if I was to use it, it'd be in a PNG decoder to support PNG covers
08:32:49Arsenthat's what I'm interested in right now
08:33:08Arsenthough, it's probably easier for me, someone with very little image format experience, to convert my covers to jpeg
08:50:11munkiswhat better way to learn about image formats?
09:54:48***No seen item changed, no save performed.
11:54:49***No seen item changed, no save performed.
12:00:09Arsennone, but it's also a significant time investment :p
12:15:16 Quit pookie (Quit: All for nothing)
12:16:02 Join olspookishmagus [0] (
13:40:35 Join advcomp2019__ [0] (~advcomp20@user/advcomp2019)
13:42:32 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:fdc4:74c:56f5:2640)
13:43:46 Quit advcomp2019_ (Ping timeout: 268 seconds)
13:54:53***Saving seen data "./dancer.seen"
14:18:39 Join lebellium [0] (
14:45:04 Join nihilazo [0] (~nihilazo@2607:f298:5:101d:f816:3eff:fe1a:29a3)
15:34:41nihilazothe function rb->lcd_bitmap in the graphics API docs says it draws a "native bitmap". What is a native bitmap?
15:35:24 Quit kugel (Ping timeout: 260 seconds)
15:35:53nihilazois that the 3bytes/pixel for RGB, 1byte/pixel on greyscale, and 1bit/pixel on b&w?
15:36:58 Join kugel [0] (
15:37:35nihilazoor should I use those lcd_grey_bitmap, lcd_mono_bitmap, and lcd_color_bitmap functions?
15:47:34nihilazolcd_color_bitmap doesn't seem to exist
15:47:43nihilazoit's not in plugin.h
15:54:55***Saving seen data "./dancer.seen"
16:41:08speachynihilazo: yes.
16:41:49speachyeach target only has one kind of lcd, so you're not going to have accss to the other lcd bitmap functions.
16:42:52nihilazoah ok, but I can't access lcd_color_bitmap on an e200 which is a color device
16:42:59nihilazoit's straight up just not in plugin.h
16:43:14speachylcd_bitmap is mapped to one of those functions
16:43:42nihilazoah ok
16:44:40nihilazoso on a color device lcd_bitmap is 3bytes/pixel, on greyscale it's 1byte/pixel, on b&w it's 1 bit?
16:44:50speachyif you don't want to deal with all that complexity, you can make your plugin only work on (eg) 16bit or >=24bit displays.
16:45:33speachywait, I take that back. rb->lcd_mono_bitmap() for 1bpp, rb->lcd_bitmap() is only there for >1bit
16:45:57speachyand it isn't necessarily 3bytes/pixel, it could be packed 16-bit eg 565 RGB
16:46:11speachyor 4-bit mono
16:46:15nihilazooh ok
16:46:43nihilazohow do I tell what the bitmap format is?
16:46:48nihilazoon a given device
16:48:10speachyeg the ipod color: #define LCD_DEPTH 16
16:48:14speachy#define LCD_PIXELFORMAT RGB565SWAPPED
16:49:02speachywe have macros and library functions for pixel-level access to bitmaps and various operations, eg blitting
16:49:31nihilazoah ok
16:50:03nihilazoright now I'm drawing to the screen (redrawing the whole screen) by plotting individual pixels in a loop
16:50:11nihilazoand I assume that drawing a bitmap is a lot faster
16:57:23 Quit nihilazo (Quit: Leaving)
17:07:48 Quit unmanbearpig (Ping timeout: 260 seconds)
17:15:31 Join unmanbearpig [0] (~unmanbear@user/unmanbearpig)
17:54:58***Saving seen data "./dancer.seen"
18:39:47 Quit ZincAlloy (Quit: Leaving.)
18:51:41 Quit lebellium (Quit: Leaving)
19:54:59***Saving seen data "./dancer.seen"
20:38:41 Join S|h|a|w|n [0] (
20:38:41 Quit S|h|a|w|n (Changing host)
20:38:41 Join S|h|a|w|n [0] (~shawn156@user/shawn/x-4432647)
20:39:07 Quit S|h|a|w|n (Client Quit)
20:39:35 Join S|h|a|w|n [0] (
20:39:35 Quit S|h|a|w|n (Changing host)
20:39:35 Join S|h|a|w|n [0] (~shawn156@user/shawn/x-4432647)
21:55:03***Saving seen data "./dancer.seen"
23:19:18 Join mendel_munkis [0] (
23:21:34 Quit munkis (Ping timeout: 268 seconds)
23:55:05***Saving seen data "./dancer.seen"

Previous day | Next day