U++ forum: Welcome to the forum

Search on this site

Search in forums

Home » U++ Library support » Draw, Display, Images, Bitmaps, Icons » bug in ImageBuffer::Line() and operator[]

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

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

Report message to a moderator

Re: bug in ImageBuffer::Line() and operator[] [message #14707 is a reply to message #14705]

Sun, 09 March 2008 22:28

mirek
Messages: 13850
Registered: November 2005

Ultimate Member

mdelfede wrote on Sun, 09 March 2008 16:21

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

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

mirek
Messages: 13850
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

I doubt it. Many things would not work if that would be the case...

Mirek

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

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

I doubt it. Many things would not work if that would be the case...

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: 13850
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

I doubt it. Many things would not work if that would be the case...

Mirek

Why ? what I'd do is :

void Draw::DrawImage(ImageBuffer & buf.....)
{
  Image Img = buf;
  DrawImage(Img......);
  buf = Img;
}

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

Report message to a moderator

Re: bug in ImageBuffer::Line() and operator[] [message #15307 is a reply to message #14746]

Wed, 16 April 2008 03:05

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

Report message to a moderator

Re: bug in ImageBuffer::Line() and operator[] [message #15326 is a reply to message #15307]

Wed, 16 April 2008 13:29

mirek
Messages: 13850
Registered: November 2005

Ultimate Member

No, nothing important has not changed.

Mirek

Report message to a moderator

Re: bug in ImageBuffer::Line() and operator[] [message #15369 is a reply to message #15326]

Thu, 17 April 2008 21:40

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

Report message to a moderator

Re: bug in ImageBuffer::Line() and operator[] [message #15370 is a reply to message #15369]

Thu, 17 April 2008 21:44

mirek
Messages: 13850
Registered: November 2005

Ultimate Member

Some thread serialization problem perhaps? Hard to say from two lines, but generally, it can be tricky Smile

Mirek

Report message to a moderator

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 328 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

mirek
Messages: 13850
Registered: November 2005

Ultimate Member

nixnixnix wrote on Tue, 15 April 2008 21:05

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

Mirek

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: 13850
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

Report message to a moderator

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

Re: bug in ImageBuffer::Line() and operator[] [message #15440 is a reply to message #15438]

Wed, 23 April 2008 21:04

mirek
Messages: 13850
Registered: November 2005

Ultimate Member

nixnixnix wrote on Wed, 23 April 2008 13:18

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

Report message to a moderator

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

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sun Mar 26 17:54:02 CEST 2023

Total time taken to generate the page: 0.01839 seconds