|
|
Home » U++ Library support » Draw, Display, Images, Bitmaps, Icons » bug in ImageBuffer::Line() and operator[]
bug in ImageBuffer::Line() and operator[] [message #14705] |
Sun, 09 March 2008 21:21  |
mdelfede
Messages: 1306 Registered: September 2007
|
Ultimate Contributor |
|
|
AFAIK ImageBuffer::Line[] (and consequently operator[]), which should return a writeable RGBA* do pick the ImageBuffer container
wiping its contents.
That makes Line() and operator[] quite useless....
Ciao
Max
|
|
|
Re: bug in ImageBuffer::Line() and operator[] [message #14707 is a reply to message #14705] |
Sun, 09 March 2008 22:28   |
 |
mirek
Messages: 13964 Registered: November 2005
|
Ultimate Member |
|
|
mdelfede wrote on Sun, 09 March 2008 16:21 | AFAIK ImageBuffer::Line[] (and consequently operator[]), which should return a writeable RGBA* do pick the ImageBuffer container
wiping its contents.
That makes Line() and operator[] quite useless....
Ciao
Max
|
I doubt it. Many things would not work if that would be the case...
Mirek
[Updated on: Sun, 09 March 2008 22:28] Report message to a moderator
|
|
|
Re: bug in ImageBuffer::Line() and operator[] [message #14708 is a reply to message #14707] |
Sun, 09 March 2008 22:46   |
mdelfede
Messages: 1306 Registered: September 2007
|
Ultimate Contributor |
|
|
luzr wrote on Sun, 09 March 2008 22:28 |
mdelfede wrote on Sun, 09 March 2008 16:21 | AFAIK ImageBuffer::Line[] (and consequently operator[]), which should return a writeable RGBA* do pick the ImageBuffer container
wiping its contents.
That makes Line() and operator[] quite useless....
Ciao
Max
|
I doubt it. Many things would not work if that would be the case...
Mirek
|
Uhmmm... I'll check it more in depth.... Somewhere my ImageBuffer is loosing its contents; it seemed to me that was just before getting RGBA pointer, but I may be wrong.
EDIT : Sorry for the wrong bug.... It was again the implied conversion between ImageBuffer and Image which wiped ImageBuffer.
I think we should really add Draw::DrawImage(ImageBuffer...) variants OR at least have some sort of message telling that
ImageBuffer was picked.
Max
[Updated on: Sun, 09 March 2008 22:52] Report message to a moderator
|
|
|
|
Re: bug in ImageBuffer::Line() and operator[] [message #14717 is a reply to message #14711] |
Mon, 10 March 2008 11:19   |
mdelfede
Messages: 1306 Registered: September 2007
|
Ultimate Contributor |
|
|
luzr wrote on Mon, 10 March 2008 09:36 |
mdelfede wrote on Sun, 09 March 2008 17:46 |
luzr wrote on Sun, 09 March 2008 22:28 |
mdelfede wrote on Sun, 09 March 2008 16:21 | AFAIK ImageBuffer::Line[] (and consequently operator[]), which should return a writeable RGBA* do pick the ImageBuffer container
wiping its contents.
That makes Line() and operator[] quite useless....
Ciao
Max
|
I doubt it. Many things would not work if that would be the case...
Mirek
|
Uhmmm... I'll check it more in depth.... Somewhere my ImageBuffer is loosing its contents; it seemed to me that was just before getting RGBA pointer, but I may be wrong.
EDIT : Sorry for the wrong bug.... It was again the implied conversion between ImageBuffer and Image which wiped ImageBuffer.
I think we should really add Draw::DrawImage(ImageBuffer...) variants OR at least have some sort of message telling that
ImageBuffer was picked.
Max
|
I think the main problem here is that it is too easy to use ImageBuffer outside of its domain.
Orginally, this was only meant to be used as local variable to create or alter Image. In that scenario there are little problems... Conversion from/to Image is very fast. However, DrawImage for ImageBuffer would be quite slow.
Mirek
|
Why ? what I'd do is :
void Draw::DrawImage(ImageBuffer & buf.....)
{
Image Img = buf;
DrawImage(Img......);
buf = Img;
}
That should work, just a few slower than original but would avoid such problems. IMHO ImageBuffer is very comfortable to create an image on the fly and draw it. Of course we can manually do what I coded above, but if you don't know the problem (or if you just don't think about it as in my case) you have a difficult to find error, as the stuff would work on first display cycle but hang on others.
Max
[Updated on: Mon, 10 March 2008 13:21] Report message to a moderator
|
|
|
Re: bug in ImageBuffer::Line() and operator[] [message #14746 is a reply to message #14717] |
Wed, 12 March 2008 14:45   |
 |
mirek
Messages: 13964 Registered: November 2005
|
Ultimate Member |
|
|
mdelfede wrote on Mon, 10 March 2008 06:19 |
luzr wrote on Mon, 10 March 2008 09:36 |
mdelfede wrote on Sun, 09 March 2008 17:46 |
luzr wrote on Sun, 09 March 2008 22:28 |
mdelfede wrote on Sun, 09 March 2008 16:21 | AFAIK ImageBuffer::Line[] (and consequently operator[]), which should return a writeable RGBA* do pick the ImageBuffer container
wiping its contents.
That makes Line() and operator[] quite useless....
Ciao
Max
|
I doubt it. Many things would not work if that would be the case...
Mirek
|
Uhmmm... I'll check it more in depth.... Somewhere my ImageBuffer is loosing its contents; it seemed to me that was just before getting RGBA pointer, but I may be wrong.
EDIT : Sorry for the wrong bug.... It was again the implied conversion between ImageBuffer and Image which wiped ImageBuffer.
I think we should really add Draw::DrawImage(ImageBuffer...) variants OR at least have some sort of message telling that
ImageBuffer was picked.
Max
|
I think the main problem here is that it is too easy to use ImageBuffer outside of its domain.
Orginally, this was only meant to be used as local variable to create or alter Image. In that scenario there are little problems... Conversion from/to Image is very fast. However, DrawImage for ImageBuffer would be quite slow.
Mirek
|
Why ? what I'd do is :
void Draw::DrawImage(ImageBuffer & buf.....)
{
Image Img = buf;
DrawImage(Img......);
buf = Img;
}
That should work, just a few slower than original but would avoid such problems. IMHO ImageBuffer is very comfortable to create an image on the fly and draw it. Of course we can manually do what I coded above, but if you don't know the problem (or if you just don't think about it as in my case) you have a difficult to find error, as the stuff would work on first display cycle but hang on others.
Max
|
Well, maybe. I do not really like the idea of non-const ImageBuffer being passed in, but that could be hidden... The only problem I see that painting the same buffer several times would be much slower that doing the same with Image.
Anyway, again, I think the main problem really is that ImageBuffer should be used as local variable only....
Or maybe we could make the situation more clear by introducing
NewImageBuffer (to create a new Image)
ImageBufferOf (to alter existing Image)
and obsoleting the direct use of ImageBuffer.
Mirek
|
|
|
|
|
|
|
Re: bug in ImageBuffer::Line() and operator[] [message #15373 is a reply to message #15370] |
Thu, 17 April 2008 22:50   |
nixnixnix
Messages: 415 Registered: February 2007 Location: Kelowna, British Columbia
|
Senior Member |
|
|
Ok it certainly appears to be an issue with Image and threading.
I reverted to a previous version of my software in which the multithreading worked but even then, when I try to repaint the view while the second thread is accessing the Image, I get the same error. It looks as though only one thread is allowed access to the Image at any one time even though both threads are pointing to the same object.
The attached testcase is a bit of a disappointment in that it does not crash but perhaps there is something dodgy about how things are getting done in it so I included it anyway.
I find in my main app that an ASSERT is failing at Image.cpp line 160.
Nick
-
Attachment: ImageMT.zip
(Size: 2.61KB, Downloaded 347 times)
[Updated on: Fri, 18 April 2008 14:45] Report message to a moderator
|
|
|
|
Re: bug in ImageBuffer::Line() and operator[] [message #15425 is a reply to message #15424] |
Wed, 23 April 2008 10:34   |
 |
mirek
Messages: 13964 Registered: November 2005
|
Ultimate Member |
|
|
void Layer::MakeLayerAsThread(Layer* pLayer,double op,void* pMain,int n)
{
ImageMT* ptr = (ImageMT*)pMain;
Layer* pNewLayer = new Layer(pLayer,op,pMain);
ptr->AddLayer(pNewLayer);
ptr->Refresh(); //<< !!! You can only do GUI in the main thread!!!
AtomicDec(ptr->threads); // the last thing this thread does is clean up
}
Calls to anything defined in CtrlCore and beyond is only allowed in the main thread, with the exception of event queue calls.
Means that instead of calling Refresh directly, you must use event queue to pass this into the main thread. Best use
void KillSetTimeCallback(int delay_ms, Callback cb, int id);
variant (to remove any other identical Refresh from the queue).
Mirek
|
|
|
Re: bug in ImageBuffer::Line() and operator[] [message #15438 is a reply to message #15425] |
Wed, 23 April 2008 19:18   |
nixnixnix
Messages: 415 Registered: February 2007 Location: Kelowna, British Columbia
|
Senior Member |
|
|
I am getting the issue under Win32 and it doesn't appear to be related to calling Refresh as I get the same behaviour when I comment it out and I have many other functions which don't suffer from this bug although I will replace these calls with PostCallback() just to be sure.
Basically the Image object causes an ASSERT(data) even though the data object is perfectly valid.
Are threads other than the main thread allowed to make and refer to Image objects?
I don't really think I understand what you're telling me here. I am allowed to use PostCallback in threads other than the main right?
Nick
[Updated on: Wed, 23 April 2008 19:54] Report message to a moderator
|
|
|
|
Goto Forum:
Current Time: Wed Nov 29 06:58:18 CET 2023
Total time taken to generate the page: 0.02327 seconds
|
|
|