Re: [bme-develop] icon loading

[Simon T. <sim...@ga...>]

[snip]
> >The GIF translator only decodes the first frame of any animated 
> > images.
> >Actually drawing them shouldn't be a problem (I have a few ideas on
> >that), once we have a list of BBitmaps for each of the frames in the
> >animation.
> >
> It's a shame the translation kit can't deal with more complex 
> format's like 
> animated gifs, and vector image formats...Btw, Simon, about that list 
> of 
> BBitmaps...we'll also need something to store the delays between 
> frames, 
> won't we? I think that also should be in the emoticon object...

Yes, I had thought of that, but forgot to mention it to you.

It should be part of the emoticon object, yes.

> >
> >I've also just made it much more lightweight, so resize performance 
> > far
> >exceeds BTextView (I've tested a BListView with 15000 NetListItems 
> > like
> >in the screenshot - still resizes in real time). Memory usuage is 
> > high
> >though (the width of every character is cached), so I might try a
> >compromise.
> >
> As I said, nice! btw Simon, I don't now for sure how you're dealing 
> with 
> those character sizes...but would it be possible to store only the 
> character 
> widths in an array? I think utf-8 hasn't to much characters, if I'm 
> not 
> mistaken, it is encoded as a byte, right? so we have 256 characters, 
> if you 
> store those 256 character lengths in an array, you needn't store that 
> much 
> information...and you can use these 256 lengths to calculate the 
> length of 
> the entire string...or am I completely mistaken? (and visualizing 
> this too 
> simple)

Yes, you are completely mistaken! UTF-8 encodes the entire unicode 
character set, some 16,000 or so characters I think. Although only a 
subset are used.

Even so, caching the width of individual characters would mean every 
time you need to calculate word wrapping, you would have to loop 
through the string, look up each individual character's width, and add 
them together. I currently store the width up to that character number 
in an array, and have a seperate array for the width up to the next 
preffered wrap point (space, dash, etc). I'm thinking of getting rid of 
the individual character caching, and just keep the wrap-point caching. 
Speed will still be blazing fast until the window is small enough that 
a single long word has to be wrapped in the middle. Then that will 
require app server calls, so will slow down. But I think for the 
majority of cases that would work fine and would save a lot of memory 
too.

> > > Not yet... mmm... I have made some changes in the Network 
> > > handlers
> > > code, change some things to get p2p messages again (somehow it 
> > > got
> > > broken when I changed to BLoopers), and a few other changes. So 
> > > far..
> > > looks good! There might be an improvement on stability ... 
> > > maybe..
> > > je,
> > > I need you guys to test it because you do a better work on 
> > > testing
> > > than
> > > I :D .
> >
> >lol no problem.
> >
> hehe, I think it's because we use it a lot, especially, now since I'm 
> almost 
> using beOS and bme all day....Do those p2p messages also have 
> something to 
> do with bme crashing when chatting with someone who uses the latest 
> windoze 
> msn? btw, great work!

I experienced that crash today too.

> > > I promise I will get it up there on friday evening (my time).
> > >
> Ok, so we'll have the code by saturday morning, thnx!
> 
> > > Good work team!!
> >
> >Yay!
> >
> Group hug :D!

lol
 
> Tim

Simon