Part of Slepp's Projects — Pastebin — TURL — Imagebin — Filebin
Feedback -- English French German Japanese
Create Upload Newest Tools Donate
Sign In | Create Account

Paste Actions

Download Raw
Embed
pBox URL
Post to Twitter
View Tree
Remove Paste

Paste Details

Raw format, 4 years 11 months old, and 653 hits.

Advertising

rockbox on-topic talk in off-top
Tuesday, June 10th, 2008 at 8:52:13am MDT 

  1. 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
  2.           Rockbox bug and therefor Rockbox is not stable like the wiki says"
  3. 16:13 < wpyh> what?
  4. 16:13 < wpyh> my 5.5g ipod is running perfectly!
  5. 16:13 < wpyh> except for the slow rendering...
  6. 16:14 < Llorean> Someone's experiencing constant freezing, and therefor thinks that Rockbox on 5.5G is completely unstable.
  7. 16:15 < LambdaCalculus37> Llorean: Where, on the forums?
  8. 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
  9.                  said a word: maybe your iPod is damaged, ever drop it?"
  10. 16:15 < Llorean> LambdaCalculus37: Most recent post I've responded to
  11. 16:15 < LambdaCalculus37> I see it.
  12. 16:15  * LambdaCalculus37 reads
  13. 16:16 < wpyh> uh
  14. 16:16 < LambdaCalculus37> He missed one critical piece of information... what SVN build?
  15. 16:17 < wpyh> right
  16. 16:17 < LambdaCalculus37> I haven't had freeze issues at all on my iPod. Slow rendering, yes. Freezes? Nope.
  17. 16:17 < wpyh> Llorean: maybe we should put user statistics up
  18. 16:17 < wpyh> download numbers may not be accurate
  19. 16:17 < Llorean> How exactly would we track who uses it?
  20. 16:17 < wpyh> LambdaCalculus37: yeah, what's up with the slow rendering?
  21. 16:17 < Llorean> wpyh: Big screen, slow processor. That simple
  22. 16:17 < wpyh> well, user statistics would be voluntary...
  23. 16:18 < LambdaCalculus37> wpyh: What Llorean said. :)
  24. 16:18 < wpyh> but the OF draws very smoothly... did it do something different?
  25. 16:19 < Llorean> The OF has hardware documentation for the broadcom processor.
  26. 16:19 < LambdaCalculus37> wpyh: That's the biggest show-stopper there.
  27. 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.
  28. 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
  29.                 font
  30. 16:20 < markun> which doesn't sound like the most efficient way to scroll a page
  31. 16:23 < wpyh> oh..
  32. 16:25 < wpyh> markun: can we have some kind of a framebuffer instead?
  33. 16:25 < markun> well, we have a framebuffer
  34. 16:26 < wpyh> um... then why do we need to redraw every character on-screen?
  35. 16:27 < gevaerts> framebuffer == what appears on screen
  36. 16:27 < markun> it's what we do, I didn't say we need to do that :)
  37. 16:27 < gevaerts> The other ways I can think of need a lot more RAM though
  38. 16:27 < wpyh> btw, isn't the broadcom processor used for video only? I didn't know it's used for lcd output
  39. 16:27  * wpyh goes to check the wiki
  40. 16:27 < Llorean> wpyh: The LCD is hooked up to it, we have to go through it for drawing
  41. 16:28 -!- toffe82 [n=chatzill@h-74-0-180-178.snvacaid.covad.net] has joined #rockbox-community
  42. 16:29 < wpyh> Llorean: ah... where can I find it in the wiki?
  43. 16:29 < Llorean> No clue
  44. 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?
  45. 16:29 < amiconn> Llorean: The data transfer through the broadcom isn't the bottleneck nowadays
  46. 16:29 < amiconn> The (somewhat) slow rendering is mainly "slow processor and big screen combo"
  47. 16:29 < wpyh> markun, gevaerts: I thought we can shift the pixels up with a framebuffer?
  48. 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
  49.                   RAM usage though
  50. 16:30 < gevaerts> wpyh: you can, but it's tricky to get it right
  51. 16:30 < wpyh> oh..
  52. 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?
  53. 16:30 < wpyh> by the way, 320*240*2=153600=150KB
  54. 16:31 < wpyh> shouldn't be too big, right?
  55. 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
  56.                  gigabeat f/x guys is actually a slowdown
  57. 16:31 < gevaerts> wpyh: unless you're careful, you'll occasionally have an off-by-one error, or forget to repaint a pixel somewhere,...
  58. 16:31 < amiconn> But I cannot prove my theory without a drawing speed test plugin
  59. 16:31 < wpyh> um...
  60. 16:32 < amiconn> Scrolling with memmove is rather trivial on 8bit and higher depth displays
  61. 16:32 < amiconn> It's rather tricky on < 8 bit depth, and we don't want two different mechanisms depending on depth
  62. 16:33 < amiconn> JdGordon: Btw, your 'stitiching together, then transfer' method is actually slower
  63. 16:33 < wpyh> maybe we can define a special memmove()?
  64. 16:33 < amiconn> ...because it involves an extra copy operation
  65. 16:33 < amiconn> wpyh: On 1 bit and 2 bit displays pixels are packed, and the packing is non-trivial
  66. 16:33 < amiconn> Take a look at the 1bit and 2bit lcd drivers to see what I mean
  67. 16:34 < amiconn> Scrolling involves bit shifting on those for one direction (vertical or horizontal, depending on pixel packing)
  68. 16:34 < Llorean> amiconn: Why don't we want tow different mechanisms?
  69. 16:34 < wpyh> let's see..
  70. 16:35 < amiconn> Llorean: Code complexity
  71. 16:35 < Llorean> If code complexity trumped performance, we wouldn't have anything ASM optimized.
  72. 16:35 < amiconn> Btw, scrolling the screen pixels is very different to our current way of scrolling. Think about background images...
  73. 16:36 -!- JdGordon is now known as JdGordon|zzz
  74. 16:36  * gevaerts forgot those...
  75. 16:36 < amiconn> Llorean: That's quite different. ASM optimisation often means replacing or modifying a low-level function to use asm code
  76. 16:37 < amiconn> Having two drawing mechanisms means rather different execution flow
  77. 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)
  78. 16:39 < gevaerts> s/<-bit/<8-bit/
  79. 16:39  * wpyh is still trying to understand the framebuffer code for 1bit lcd
  80. 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)
  81. 16:40 < wpyh> oh no :O
  82. 16:41 < amiconn> gevaerts: Yes. And btw, the background image problem remains
  83. 16:41 < wpyh> background image problem?
  84. 16:42 < wpyh> you mean the background image being also "scrolled"?
  85. 16:42 < gevaerts> yes
  86. 16:42 < wpyh> then we can't use this approach
  87. 16:42 < wpyh> let's use multilevel buffers
  88. 16:42 < amiconn> More buffers will make things slower, not faster
  89. 16:43 < markun> wpyh: one big slowdown is also the fontcache which kicks in with big fonts (in bytes, not pixels)
  90. 16:43 < wpyh> it would increase complexity though..
  91. 16:43 < markun> can you try with a small font (in bytes) to see if the interface is faster?
  92. 16:43 < wpyh> markun: reminds me of the Chinese fonts
  93. 16:43 < markun> I promissed amiconn some years ago that I would reimplement it and actually worked on it
  94. 16:44 < markun> we should do a rockbox summer camp! :)
  95. 16:44  * gevaerts proposes a dynamically sized font cache, and quickly hides under the table
  96. 16:44 < wpyh> that would be great
  97. 16:44 < wpyh> I mean a summer camp, not the dynamically sized font cache
  98. 16:44 < wpyh> :p
  99. 16:44 < markun> :)
  100. 16:44  * GodEater proposes this all moves back to #rockbox
  101. 16:45 < markun> GodEater: even the summer camp? :)
  102. 16:45 < gevaerts> GodEater: even disguises malloc() proposals? :)
  103. 16:45 < GodEater> yes, it's on topic
  104. 16:45 < GodEater> even if it's going to raise merry hell ;)
  105. 16:46  * wpyh wonders whether someone should copy & paste the whole discussion to #rockbox
  106. 16:46 < LambdaCalculus37> :)
  107. 16:46 < GodEater> pastebin it

advertising

Update the Post

Either update this post and resubmit it with changes, or make a new post.

You may also comment on this post.

update paste below
details of the post (optional)

Note: Only the paste content is required, though the following information can be useful to others.

Save name / title?

(space separated, optional)



Please note that information posted here will expire by default in one month. If you do not want it to expire, please set the expiry time above. If it is set to expire, web search engines will not be allowed to index it prior to it expiring. Items that are not marked to expire will be indexable by search engines. Be careful with your passwords. All illegal activities will be reported and any information will be handed over to the authorities, so be good.

worth-right
fantasy-obligation