Image Corruption

18 views
Skip to first unread message

Dylan Taft

unread,
Jan 5, 2017, 4:18:10 AM1/5/17
to fltk.general
http://i.imgur.com/DMw3I1t.png

On the second monitor, images go crazy if I hide and unhide the window.  The main screen it works fine.  This is on Linux.

The std::cout shows that the image has 0,0,0,0 in the data at the location it's screwing up.

Is this a driver issue, probably?
Are there any other backends for FLTK?

I'm not wrong to subclass Fl_Window as I am, or use transparencies with Fl_RGB_Image?

Duncan Gibson

unread,
Jan 5, 2017, 5:38:19 AM1/5/17
to fltkg...@googlegroups.com
Sorry, can't help you because the firewall blocks access to pastebin
[and probably wouldn't be able to help even if I could see the code]

In any case, netiquette suggests that you should post small snippets
of the code inline, and attach images to the email, so that they are
all kept together in the archive and other people can refer to them
even once they been wiped from the caches of the paste/image sites.

If you can post a small compilable example of code, inline, that
demonstrates the problem, people are more likely to be able to help.

D.

This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.


Albrecht Schlosser

unread,
Jan 5, 2017, 7:24:26 AM1/5/17
to fltkg...@googlegroups.com
On 05.01.2017 11:38 Duncan Gibson wrote:
> Sorry, can't help you because the firewall blocks access to pastebin
> [and probably wouldn't be able to help even if I could see the code]
>
> In any case, netiquette suggests that you should post small snippets
> of the code inline, and attach images to the email, so that they are
> all kept together in the archive and other people can refer to them
> even once they been wiped from the caches of the paste/image sites.
>
> If you can post a small compilable example of code, inline, that
> demonstrates the problem, people are more likely to be able to help.

I took a look at the code at pastebin and it uses OpenCV, so I may add
that the OP should post a simple FLTK-only code sample that shows the
issue. Otherwise I (and maybe other helpful FLTK users) won't be able to
reproduce the issue or even understand the code so far as necessary to
point out errors. And it's very likely that OpenCV may be involved in
the issue.

@OP:

If you post images, please do also show the expected (i.e. working)
image so we can see what's wrong. In your posted image I assume the gray
and black shaded rectangle should not be there? What about the black
part of the background? Are the yellow and blue "hello" paintings both
intended?

And, last but not least, which FLTK version did you use? The OS version
(not only "Linux") and graphics type/driver could be helpful as well in
this particular case.

Albrecht Schlosser

unread,
Jan 5, 2017, 4:42:32 PM1/5/17
to fltk.general
On 05.01.2017 20:45 Dylan Taft wrote:

> FLTK 1.3.3-8 on Ubuntu 16.10. This actually works on FLTK 1.3.4-1

Okay...

> The image shows both - the left side is on one monitor and is correct,
> the right side is on the other and is incorrect - the transparent areas,
> where the alpha channel is set to 0, is all odd. The RGB channel data
> where there is black or odd corruption on the right is actually 0,0,0.
>
> I can downgrade to 1.3.3-8 and make a real test case - but I can't
> reproduce this on 1.3.4-1 anymore.

That's good to know. Thanks for the feeadback.

> There's a ton more information I could provide, Xorg version, radeon
> driver(open source) version, Xorg config file.

Not necessary, thanks.

> If it's fixed in 1.3.4-1, and this specifically seemed to deal with
> transparency - is anyone still interested in additional details and a
> test case?

No, thanks. There have been improvements WRT image drawing,
transparency, and maybe (second) monitor issues in 1.3.4, but I don't
remember all the details. If it's fixed for you in 1.3.4 then it's okay.

Dylan Taft

unread,
Jan 5, 2017, 5:22:05 PM1/5/17
to fltk.general, Albrech...@online.de


On Thursday, January 5, 2017 at 7:24:26 AM UTC-5, Albrecht Schlosser wrote:
If you post images, please do also show the expected (i.e. working)
image so we can see what's wrong. In your posted image I assume the gray
and black shaded rectangle should not be there? What about the black
part of the background? Are the yellow and blue "hello" paintings both
intended?

And, last but not least, which FLTK version did you use? The OS version
(not only "Linux") and graphics type/driver could be helpful as well in
this particular case.

FLTK 1.3.3-8 on Ubuntu 16.10.  This actually works on FLTK 1.3.4-1 
The image shows both - the left side is on one monitor and is correct, the right side is on the other and is incorrect - the transparent areas, where the alpha channel is set to 0, is all odd.  The RGB channel data where there is black or odd corruption on the right is actually 0,0,0.

I can downgrade to 1.3.3-8 and make a real test case - but I can't reproduce this on 1.3.4-1 anymore. 
There's a ton more information I could provide, Xorg version, radeon driver(open source) version, Xorg config file.

If it's fixed in 1.3.4-1, and this specifically seemed to deal with transparency - is anyone still interested in additional details and a test case?

Anyway, thanks, and sorry for the limited information in the OP.


Reply all
Reply to author
Forward
0 new messages