16:13 * Llorean wishes people would stop making wild assumptions like "nobody cares about the 5.5G port" or "my iPod is perfect, so this bug must be a giant
Rockbox bug and therefor Rockbox is not stable like the wiki says"
16:13 < wpyh> what?
16:13 < wpyh> my 5.5g ipod is running perfectly!
16:13 < wpyh> except for the slow rendering...
16:14 < Llorean> Someone's experiencing constant freezing, and therefor thinks that Rockbox on 5.5G is completely unstable.
16:15 < LambdaCalculus37> Llorean: Where, on the forums?
16:15 < Llorean> Maybe we should just post download numbers of some sort, so people can see "look, there's probably a few thousand other users who haven't
said a word: maybe your iPod is damaged, ever drop it?"
16:15 < Llorean> LambdaCalculus37: Most recent post I've responded to
16:15 < LambdaCalculus37> I see it.
16:15 * LambdaCalculus37 reads
16:16 < wpyh> uh
16:16 < LambdaCalculus37> He missed one critical piece of information... what SVN build?
16:17 < wpyh> right
16:17 < LambdaCalculus37> I haven't had freeze issues at all on my iPod. Slow rendering, yes. Freezes? Nope.
16:17 < wpyh> Llorean: maybe we should put user statistics up
16:17 < wpyh> download numbers may not be accurate
16:17 < Llorean> How exactly would we track who uses it?
16:17 < wpyh> LambdaCalculus37: yeah, what's up with the slow rendering?
16:17 < Llorean> wpyh: Big screen, slow processor. That simple
16:17 < wpyh> well, user statistics would be voluntary...
16:18 < LambdaCalculus37> wpyh: What Llorean said. :)
16:18 < wpyh> but the OF draws very smoothly... did it do something different?
16:19 < Llorean> The OF has hardware documentation for the broadcom processor.
16:19 < LambdaCalculus37> wpyh: That's the biggest show-stopper there.
16:19 < Llorean> It probably also makes better use of the second core in the PP processor, which we only really use for video right now.
16:19 < markun> some things could probably be done faster in rockbox too, since we now just redraw every character on screen by looking the glyph up in the
font
16:20 < markun> which doesn't sound like the most efficient way to scroll a page
16:23 < wpyh> oh..
16:25 < wpyh> markun: can we have some kind of a framebuffer instead?
16:25 < markun> well, we have a framebuffer
16:26 < wpyh> um... then why do we need to redraw every character on-screen?
16:27 < gevaerts> framebuffer == what appears on screen
16:27 < markun> it's what we do, I didn't say we need to do that :)
16:27 < gevaerts> The other ways I can think of need a lot more RAM though
16:27 < wpyh> btw, isn't the broadcom processor used for video only? I didn't know it's used for lcd output
16:27 * wpyh goes to check the wiki
16:27 < Llorean> wpyh: The LCD is hooked up to it, we have to go through it for drawing
16:28 -!- toffe82 [n=chatzill@h-74-0-180-178.snvacaid.covad.net] has joined #rockbox-community
16:29 < wpyh> Llorean: ah... where can I find it in the wiki?
16:29 < Llorean> No clue
16:29 < JdGordon> are the glyphs still drawn one at a time instead of stitching them together into a bmp buffer and then drawing that buffer in 1 hit?
16:29 < amiconn> Llorean: The data transfer through the broadcom isn't the bottleneck nowadays
16:29 < amiconn> The (somewhat) slow rendering is mainly "slow processor and big screen combo"
16:29 < wpyh> markun, gevaerts: I thought we can shift the pixels up with a framebuffer?
16:30 < gevaerts> JdGordon: I'd say the main optimisation would be to then keep that bmp buffer around and reuse it next time you draw the same text. Lots of
RAM usage though
16:30 < gevaerts> wpyh: you can, but it's tricky to get it right
16:30 < wpyh> oh..
16:30 < Llorean> amiconn: Depending on what the broadcom chip is capable of, though, might it be possible to offload the drawing work to it?
16:30 < wpyh> by the way, 320*240*2=153600=150KB
16:31 < wpyh> shouldn't be too big, right?
16:31 < amiconn> The mono bitmap drawing has some possibilities for optiomisation, and I still think that the "optimisation" introduced by one of the early
gigabeat f/x guys is actually a slowdown
16:31 < gevaerts> wpyh: unless you're careful, you'll occasionally have an off-by-one error, or forget to repaint a pixel somewhere,...
16:31 < amiconn> But I cannot prove my theory without a drawing speed test plugin
16:31 < wpyh> um...
16:32 < amiconn> Scrolling with memmove is rather trivial on 8bit and higher depth displays
16:32 < amiconn> It's rather tricky on < 8 bit depth, and we don't want two different mechanisms depending on depth
16:33 < amiconn> JdGordon: Btw, your 'stitiching together, then transfer' method is actually slower
16:33 < wpyh> maybe we can define a special memmove()?
16:33 < amiconn> ...because it involves an extra copy operation
16:33 < amiconn> wpyh: On 1 bit and 2 bit displays pixels are packed, and the packing is non-trivial
16:33 < amiconn> Take a look at the 1bit and 2bit lcd drivers to see what I mean
16:34 < amiconn> Scrolling involves bit shifting on those for one direction (vertical or horizontal, depending on pixel packing)
16:34 < Llorean> amiconn: Why don't we want tow different mechanisms?
16:34 < wpyh> let's see..
16:35 < amiconn> Llorean: Code complexity
16:35 < Llorean> If code complexity trumped performance, we wouldn't have anything ASM optimized.
16:35 < amiconn> Btw, scrolling the screen pixels is very different to our current way of scrolling. Think about background images...
16:36 -!- JdGordon is now known as JdGordon|zzz
16:36 * gevaerts forgot those...
16:36 < amiconn> Llorean: That's quite different. ASM optimisation often means replacing or modifying a low-level function to use asm code
16:37 < amiconn> Having two drawing mechanisms means rather different execution flow
16:38 < gevaerts> amiconn: you mean memmove-based scrolling on 8+-bit lcds and redraw-based on <-bit ? (That's how I understood you, but I'm not sure)
16:39 < gevaerts> s/<-bit/<8-bit/
16:39 * wpyh is still trying to understand the framebuffer code for 1bit lcd
16:40 < amiconn> wpyh: 1 bit is in fact the simplest one of the packed-pixel formats. 2 bit is more complicated (and exists with 3 different pixel packings)
16:40 < wpyh> oh no :O
16:41 < amiconn> gevaerts: Yes. And btw, the background image problem remains
16:41 < wpyh> background image problem?
16:42 < wpyh> you mean the background image being also "scrolled"?
16:42 < gevaerts> yes
16:42 < wpyh> then we can't use this approach
16:42 < wpyh> let's use multilevel buffers
16:42 < amiconn> More buffers will make things slower, not faster
16:43 < markun> wpyh: one big slowdown is also the fontcache which kicks in with big fonts (in bytes, not pixels)
16:43 < wpyh> it would increase complexity though..
16:43 < markun> can you try with a small font (in bytes) to see if the interface is faster?
16:43 < wpyh> markun: reminds me of the Chinese fonts
16:43 < markun> I promissed amiconn some years ago that I would reimplement it and actually worked on it
16:44 < markun> we should do a rockbox summer camp! :)
16:44 * gevaerts proposes a dynamically sized font cache, and quickly hides under the table
16:44 < wpyh> that would be great
16:44 < wpyh> I mean a summer camp, not the dynamically sized font cache
16:44 < wpyh> :p
16:44 < markun> :)
16:44 * GodEater proposes this all moves back to #rockbox
16:45 < markun> GodEater: even the summer camp? :)
16:45 < gevaerts> GodEater: even disguises malloc() proposals? :)
16:45 < GodEater> yes, it's on topic
16:45 < GodEater> even if it's going to raise merry hell ;)
16:46 * wpyh wonders whether someone should copy & paste the whole discussion to #rockbox
16:46 < LambdaCalculus37> :)
16:46 < GodEater> pastebin it