--- Log for 02.11.121 Server: sodium.libera.chat Channel: #rockbox --- Nick: rb-logbot Version: Dancer V4.16 Started: 22 hours and 41 minutes ago 00.35.16 Join akaWolf [0] (~akaWolf@akawolf.org) 01.46.02 Quit pixelma (Quit: .) 01.46.02 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 01.48.33 Join amiconn [0] (jens@p200300ea871d8200305e95fffec66ff3.dip0.t-ipconnect.de) 01.48.33 Join pixelma [0] (marianne@p200300ea871d8200305e95fffec66ff3.dip0.t-ipconnect.de) 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 (~fun@chui-pas.net) 05.43.35 Quit wolfshappen (Ping timeout: 260 seconds) 05.43.43 Join wolfshappen_ [0] (~waff@irc.furworks.de) 05.54.41 *** Saving seen data "./dancer.seen" 06.14.22 # good news friends: https://github.com/beetbox/beets/pull/4029 06.14.32 # if you're using beets, it'll now make covers work on rockbox 06.14.38 # (or rather, have the option to) 06.14.44 # on that note, rockbox doesn't do PNG, right? 06.18.44 # I think so. It's been a while since I looked... 06.45.46 # correct. nobody's written a row-based decoder yet. 06.54.35 # is that even possible for PNG? 06.54.48 # I haven't looked into the format before, or any image format other than gif really 06.58.01 # IIRC 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.03 # I want to say you'll need a minimum of 64K of buffer, plus more for the decompressor state (eg huffman tables) 07.00.46 # that doesn't sound impossible, though I've never implemented either zlib nor png before 07.00.48 # whereas 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.19 # ok, png uses deflate/inflate, with a window of 32K 07.01.48 # (well, "of at most 32768 bytes" 07.04.30 # it's not impossible but would effectively require a completely independent libpng-api-incompatible decoder implementation. 07.05.39 # well, yeah, that's to be expected, right? 07.12.53 # https://github.com/bitbank2/PNGdec 07.13.19 # looks like someone might have done it for us already. 48K RAM required. 07.14.32 # line-by-line decoding using a callback. 07.19.48 # this didnt' exist the last time I looked 07.53.07 # ooh, nice 07.53.56 # I imagine you might want to modify it somewhat to use an existing zlib implementation, if one exists? 07.54.05 # (in rockbox that is) 07.54.44 *** No seen item changed, no save performed. 07.58.13 # imageviewer plugin already decodes png's 07.59.26 # based on https://lodev.org/lodepng/ 08.14.03 # Arsen: the regular png library has an API for decoding one row of pixels at a time. 08.14.09 # beyond that I don't know anything 08.16.20 # ah. 08.16.25 # png_read_row 08.17.17 # Arsen: fyi we already have a zlib alternative in core. my inflate code. only does decompression. 08.17.30 # yeah, I expected that 08.17.39 # that's why I asked 08.17.56 # it was intended for ZIP files but can be used for png data 08.19.11 # it's faster and a bit bulkier than tinf but it's a good balance for the code size i think 08.19.44 # still slower than zlib but not nearly as fat 08.32.17 # Arsen: 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.29 # not hard to add support though 08.32.36 # the api was kept fairly simple 08.32.42 # braewoods: if I was to use it, it'd be in a PNG decoder to support PNG covers 08.32.49 # that's what I'm interested in right now 08.33.08 # though, it's probably easier for me, someone with very little image format experience, to convert my covers to jpeg 08.50.11 # what 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.09 # none, but it's also a significant time investment :p 12.15.16 Quit pookie (Quit: All for nothing) 12.16.02 Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) 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] (~lebellium@2a01cb04012c0900b03a0572d584cc36.ipv6.abo.wanadoo.fr) 14.45.04 Join nihilazo [0] (~nihilazo@2607:f298:5:101d:f816:3eff:fe1a:29a3) 15.34.41 # the 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.53 # is that the 3bytes/pixel for RGB, 1byte/pixel on greyscale, and 1bit/pixel on b&w? 15.36.58 Join kugel [0] (~kugel@ip5f59a293.dynamic.kabel-deutschland.de) 15.37.35 # or should I use those lcd_grey_bitmap, lcd_mono_bitmap, and lcd_color_bitmap functions? 15.47.34 # lcd_color_bitmap doesn't seem to exist 15.47.43 # it's not in plugin.h 15.54.55 *** Saving seen data "./dancer.seen" 16.41.08 # nihilazo: yes. 16.41.49 # each target only has one kind of lcd, so you're not going to have accss to the other lcd bitmap functions. 16.42.52 # ah ok, but I can't access lcd_color_bitmap on an e200 which is a color device 16.42.59 # it's straight up just not in plugin.h 16.43.14 # lcd_bitmap is mapped to one of those functions 16.43.42 # ah ok 16.44.40 # so on a color device lcd_bitmap is 3bytes/pixel, on greyscale it's 1byte/pixel, on b&w it's 1 bit? 16.44.50 # if you don't want to deal with all that complexity, you can make your plugin only work on (eg) 16bit or >=24bit displays. 16.44.52 # yeah 16.45.33 # wait, I take that back. rb->lcd_mono_bitmap() for 1bpp, rb->lcd_bitmap() is only there for >1bit 16.45.57 # and it isn't necessarily 3bytes/pixel, it could be packed 16-bit eg 565 RGB 16.46.11 # or 4-bit mono 16.46.15 # oh ok 16.46.43 # how do I tell what the bitmap format is? 16.46.48 # on a given device 16.47.54 # HAVE_LCD_COLOR, LCD_DEPTH, and LCD_PIXELFORMAT 16.48.10 # eg the ipod color: #define LCD_DEPTH 16 16.48.14 # #define LCD_PIXELFORMAT RGB565SWAPPED 16.49.02 # we have macros and library functions for pixel-level access to bitmaps and various operations, eg blitting 16.49.31 # ah ok 16.50.03 # right now I'm drawing to the screen (redrawing the whole screen) by plotting individual pixels in a loop 16.50.11 # and 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] (~shawn156@c-76-25-73-212.hsd1.co.comcast.net) 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] (~shawn156@c-76-25-73-212.hsd1.co.comcast.net) 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] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) 23.21.34 Quit munkis (Ping timeout: 268 seconds) 23.55.05 *** Saving seen data "./dancer.seen"