I have a large number of bitmaps (all the same bitmap data) which I want to change the source bitmap of on the fly. When I change the MUIA_Bitmap_Bitmap at the moment, nothing happens until I iconify and bring back the window - at which point it all looks correct.
How can I force MUI to change the bitmap source data safely and cleanly?
I think I may need to make a subclass but I'm not sure how to do this with a Bitmap class and make it able to use the standard MUI bitmap class but redraw it on demand.
When I change the MUIA_Bitmap_Bitmap at the moment, nothing happens until I iconify and bring back the window
That's strange, because that's what eGame is doing at the moment, and it Works For Me (TM).
set(object, MUIA_Bitmap_Bitmap, newBitmap)
For AROS's Zune I did have to kludge it to refresh, but I assumed this was a bug (since it works on MorphOS as well as OS4 when I do it). Here was my kludge (don't do this at home!) : set(object, MUIA_ShowMe, MUI_FALSE) set(object, MUIA_ShowMe, MUI_TRUE)
@tboeckel Any idea why it works for me? And why doesn't MUI act intelligently & refresh the bitmap when it is changed (in some circumstances anyway)?
ChrisH wrote: That's strange, because that's what eGame is doing at the moment, and it Works For Me (TM).
set(object, MUIA_Bitmap_Bitmap, newBitmap)
Most probably you didn't use MUIA_Bitmap_SourceColors then (or any other attribute which might cause the bitmap to be remapped). In this case setting a new bitmap will correctly redraw the new one. Otherwise you will also trigger a redraw event, but still with the old bitmap.
Quote:
For AROS's Zune I did have to kludge it to refresh, but I assumed this was a bug since MorphOS as well as OS4 when I do it. Here was my kludge (don't do this at home!) : set(object, MUIA_ShowMe, MUI_FALSE) set(object, MUIA_ShowMe, MUI_TRUE)
This is almost the same as removing and readding the bitmap object, but a little bit worse as this will effectively cause two refresh cycles instead of just one.
Quote:
@tboeckel Any idea why it works for me? And why doesn't MUI act intelligently & refresh the bitmap when it is changed (in some circumstances anyway)?
I cannot really tell why stunzi implemented it this way. I guess it was done this way because usually people use the set() macro instead of SetAttrs() directly. The macro allows to modify one attribute with each call only. The point is that modifying the bitmap might require more than one attribute to be changed (mask, colors, etc). Setting all these attributes with single set() calls instead of one SetAttrs() call would have resulted in a redraw action for each set() call. And even worse it even might cause graphical garbage if the old mask is applied to the new bitmap.
Most probably you didn't use MUIA_Bitmap_SourceColors then (or any other attribute which might cause the bitmap to be remapped). In this case setting a new bitmap will correctly redraw the new one. Otherwise you will also trigger a redraw event, but still with the old bitmap.
That's correct, I had already manually remapped the bitmap to the screen, so it doesn't need remapping further. Probably not advisable to normal MUI programs (which could in principle change screens at any time), but I think (may be wrong) that I forced which screen my windows appear on.
Hi, I'm playing too with MUI Bitmap, contrary to you, I don't have problem to update my Bitmap but my program (and the OS) freezes when I deiconify my program. Do you do something special to prepare the deiconification of your Bitmap ? When I remove it, in iconification phase with REMMEMBER, and not readd it during deiconification, it works.
I have tried the InitCHange, ExitChange method, but it freezes, when I do the following in the deiconification
I'm playing too with MUI Bitmap, contrary to you, I don't have problem to update my Bitmap but my program (and the OS) freezes when I deiconify my program.
A simple system freeze is not much of a basis to help you. Is there anything on the serial line?
Thank you by advance if you have a clue (even if you don't have...)
Well, there is nothing special in the log except that the crash is finally happening in rtg.library. How do you create the bitmap? Is it possible that it might become invalid when the application is iconified and hence invalid pointers will be accessed upon uniconification?
I create the MUI_Bitmap by passing to it a Bitmap struct created by Datatype. You think that the struct Bitmap bitmap_vignette could be corrupted when I iconify/deiconify, it's ?
In my global variables : struct BitMap *bitmap_vignette = NULL;
I create the MUI_Bitmap by passing to it a Bitmap struct created by Datatype.
What happens to the DT object after you obtained the bitmap from it? Of course it must stay alive as long as the bitmap is used by your Bitmap object, because DisposeDTObject() will free all stuff belonging to the object, including the bitmap you obtained before. If you implemented things really this way, the you must clone the obtained bitmap before you dispose the DT object and use the cloned bitmap for your Bitmap object.