[BeOS]nsImage IS optimized after CreateImage



Core Graveyard
13 years ago
7 years ago


(Reporter: Sergei Dolgov, Assigned: Sergei Dolgov)


Firefox Tracking Flags

(Not tracked)




13 years ago
currently we set mOptimized flag to true only in exlicit :Optimize() call.
Actually it must be set in CreateImage().
1)if void CreateImage fails, flag in Oprimize() would be set anyway, which is wrong.
2)If Optimize() is called after CreateImage(), it may result in overhead of rebuilding native image.


13 years ago
Summary: [BeOS]nsImage IS optimized after CreateImage thesuckiestemail@yahoo.se cbiesinger@gmx.at → [BeOS]nsImage IS optimized after CreateImage

Comment 1

13 years ago
situation is but more tricky.
We rather should care about avoiding extra work in CreateImage than changing place for mOptimized flag.

Comment 2

13 years ago
Interestingly, according to lxr, nsImage*::Optimize() is unused outside.
It means for BeOS we always have both mozilla image bits and native BBitmap - almoust doubling memory consumption.
It may add speed, though, as no need to convert BBitmap to native bits in LockImagePixels..
But with this our UnlockImageBits() looks bit wrong. Probably it should call ::ImageUpdated(), to inform nsImageBeOS about need to invalidate BBitmap.

Comment 4

13 years ago
Hmm, so decoders really use Optimize() by calling SetMutable() .
But then there is still question, why we didn't notice till now any big issue regarding LockImageBits(), because after Optimize() platform-independent bits are 
 gone and set to nsnull. So GetBits() called after LockImageBits() in our case may happen to provide nihil to caller.
I don't think that there are many callers of that...
Product: Core → Core Graveyard
We don't support BeOS any more.
Last Resolved: 7 years ago
Resolution: --- → INVALID

Comment 7

7 years ago
In the graveyard, code referred to doesn't exist to be fixed.
You need to log in before you can comment on or make changes to this bug.