Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
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 Go to next message
mdelfede is currently offline  mdelfede
Messages: 1259
Registered: September 2007
Senior 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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12105
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 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1259
Registered: September 2007
Senior 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 #14711 is a reply to message #14708] Mon, 10 March 2008 09:36 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12105
Registered: November 2005
Ultimate Member
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
Re: bug in ImageBuffer::Line() and operator[] [message #14717 is a reply to message #14711] Mon, 10 March 2008 11:19 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1259
Registered: September 2007
Senior 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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12105
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 #15307 is a reply to message #14746] Wed, 16 April 2008 03:05 Go to previous messageGo to next message
nixnixnix is currently offline  nixnixnix
Messages: 415
Registered: February 2007
Location: Kelowna, British Columbia
Senior Member
Hi Mirek,

Did something change recently in the behaviour of Image?

I have some code which used to work fine (I just checked with an old executable) but now its broken.

I'm getting an error that data=zero when I pass a pointer to an object containing an Image to a new Thread for processing. If I choose to run the static function in the same thread its fine (but obviously I dont want to do that as its clunky) but if I spawn a new thread I can access all other properties of my object except the Image member's data.

Nick
Re: bug in ImageBuffer::Line() and operator[] [message #15326 is a reply to message #15307] Wed, 16 April 2008 13:29 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12105
Registered: November 2005
Ultimate Member
No, nothing important has not changed.

Mirek
Re: bug in ImageBuffer::Line() and operator[] [message #15369 is a reply to message #15326] Thu, 17 April 2008 21:40 Go to previous messageGo to next message
nixnixnix is currently offline  nixnixnix
Messages: 415
Registered: February 2007
Location: Kelowna, British Columbia
Senior Member
Is there any reason you can think of that the first line below would result in accessing an Image member with no data whilst the second call would work fine? (both versions did work at one point)

Thread().Run(callback4(&RasterLayer::MakeImageRasterAsThreadNoKey,pLayer,m_ptr,m_convertImage,0));

RasterLayer::MakeImageRasterAsThreadNoKey(pLayer,m_ptr,m_convertImage,0);



Nick
Re: bug in ImageBuffer::Line() and operator[] [message #15370 is a reply to message #15369] Thu, 17 April 2008 21:44 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12105
Registered: November 2005
Ultimate Member
Some thread serialization problem perhaps? Hard to say from two lines, but generally, it can be tricky Smile

Mirek
Re: bug in ImageBuffer::Line() and operator[] [message #15373 is a reply to message #15370] Thu, 17 April 2008 22:50 Go to previous messageGo to next message
nixnixnix is currently offline  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 226 times)

[Updated on: Fri, 18 April 2008 14:45]

Report message to a moderator

Re: bug in ImageBuffer::Line() and operator[] [message #15424 is a reply to message #15307] Wed, 23 April 2008 10:25 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12105
Registered: November 2005
Ultimate Member
nixnixnix wrote on Tue, 15 April 2008 21:05

Hi Mirek,

Did something change recently in the behaviour of Image?

I have some code which used to work fine (I just checked with an old executable) but now its broken.

I'm getting an error that data=zero when I pass a pointer to an object containing an Image to a new Thread for processing. If I choose to run the static function in the same thread its fine (but obviously I dont want to do that as its clunky) but if I spawn a new thread I can access all other properties of my object except the Image member's data.

Nick


Is it Win32 or Linux issue? (See my other reply/fix).

Mirek
Re: bug in ImageBuffer::Line() and operator[] [message #15425 is a reply to message #15424] Wed, 23 April 2008 10:34 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12105
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 Go to previous messageGo to next message
nixnixnix is currently offline  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

Re: bug in ImageBuffer::Line() and operator[] [message #15440 is a reply to message #15438] Wed, 23 April 2008 21:04 Go to previous message
mirek is currently offline  mirek
Messages: 12105
Registered: November 2005
Ultimate Member
nixnixnix wrote on Wed, 23 April 2008 13:18

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?



Yes. Anyway, as always with MT, if multiple threads work with single Image variable, you need to serialize access via Mutex.

Quote:


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?



Yes, but ONLY PostCallback (and related event queue functions). Anything else in CtrlCore and beyond (-> CtrlLib, RichEdit... anything that includes CtrlCore) is disallowed.

(Draw, OTOH, you can use in multiple threads).

Mirek
Previous Topic: problems drawing in Linux (ubuntu 7.10)
Next Topic: Bug: ImageBuffer::alpha not initialised on X11
Goto Forum:
  


Current Time: Wed Nov 20 18:21:11 CET 2019

Total time taken to generate the page: 0.01274 seconds