RE: [fltk.general] Re: Too bright with new nVidia driver - [General Use]

52 views
Skip to first unread message

MacArthur, Ian (Leonardo, UK)

unread,
Oct 19, 2018, 8:36:03 AM10/19/18
to fltkg...@googlegroups.com

> Sorry, forgot to mention that I use FLTK 1.3.3.

> On Friday, October 19, 2018 at 2:18:31 PM UTC+2, ekstrand wrote:
> Hi all,

> My Fl_Gl_Window is suddently too bright after update to the new nVidia
> driver (happened in 411.63 and also in new 416.16). I can see that even
> the glpuzzle test produces too bright colors. The background color
> (glClearColor) is e.g. set to (0.5, 0.5, 0.5) but is rendered as (0.74,
> 0.74, 0.74). Maybe some gamma issue?

> I haven't observed this in any other applications but the same happens
> in my FLTK based application on another computer, both with Geforce GTX
> 970.

> Has anyone else experienced this? Any idea of how to solve it?

I don't have a useful answer to this - other than to say that yes, ISTR that we did see reports of this before, and it seemed to be GPU driver related, or something.

Only, I can't now find the relevant thread, nor what the outcome was, either.

Have you tried a more recent snapshot?
If there was a fltk issue it may well be resolved in the current files, post that prior discussion.

But... I think it was some sort of display gamma choice the driver was making that was "outside" fltk's control, maybe.
Indeed, ISTR that the OP reported that if they attached 2 monitors, they saw different colours on the 2 monitors as the driver was making "different choices" for each monitor.
(I don't think I'm making that up, it is what I remember, but who knows!)



Leonardo MW Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

MacArthur, Ian (Leonardo, UK)

unread,
Oct 19, 2018, 8:51:15 AM10/19/18
to fltkg...@googlegroups.com
Might have been this thread, but I am not sure...


https://groups.google.com/d/msg/fltkgeneral/u2Z895T_XSM/5xjD_P_lAAAJ

ekstrand...@gmail.com

unread,
Oct 19, 2018, 10:14:42 AM10/19/18
to fltk.general
Yes, I tried in 1.4.x-r13071 as well with the same result. By the way, I'm using Windows 10.

Thanks, I took the following fix made by Anthony in the thread you pointed out and it worked:

// otherwise more bit planes is better, but no more than 32 (8 bits per channel):
else if (pfd.cColorBits > 32 || chosen_pfd.cColorBits > pfd.cColorBits) continue;

I guess this was too specific and limiting to include generally in FLTK? But I could use it here in my tweaked FLTK.

/Andreas

Albrecht Schlosser

unread,
Oct 19, 2018, 1:22:32 PM10/19/18
to fltkg...@googlegroups.com
On 19.10.2018 16:14 ekstrand...@gmail.com wrote:
> Yes, I tried in 1.4.x-r13071 as well with the same result. By the way,
> I'm using Windows 10.
>
> Thanks, I took the following fix made by Anthony in the thread you
> pointed out and it worked:
>
> // otherwise more bit planes is better, but no more than 32 (8 bits per
> channel):
> else if (pfd.cColorBits > 32 || chosen_pfd.cColorBits > pfd.cColorBits)
> continue;
>
> I guess this was too specific and limiting to include generally in FLTK?

No, not too limiting IMHO, but the selection of pixel formats depends on
so many different items that it is hardly predictable in any case. We
have STR #3119 with a similar issue that was pending for a long time
because it was so difficult to decide w/o test systems.

Anyway, I modified the patch given in STR #3119 and added that bit you
cited and tested and committed this in svn r 13072 in the FLTK 1.4.0
branch. The next snapshot is due tomorrow morning...

So please test and give feedback if the modified 1.4 version works for you.

I also created a patch for 1.3.4 (actually to be 1.3.5) that can be
downloaded from the STR form at:

http://www.fltk.org/str.php?L3119
http://www.fltk.org/strfiles/3119/support_composition_v3_r13071_1.3.diff

Please test and give feedback in the STR form (and optionally here too)
if it works for you with the additional changes in the patch. You can
also enable debug output as described in STR #3119, comment #8.

I'd like to commit it to 1.3.5 as well, but I'm not yet sure if it
doesn't break other graphics environments.

All feedback welcome. TIA.

ekstrand...@gmail.com

unread,
Oct 20, 2018, 5:17:01 PM10/20/18
to fltk.general
Thanks for the great support as always, Albrecht! Both latest 1.4 and the 1.3 patch work great for me.
/Andreas

Albrecht Schlosser

unread,
Oct 20, 2018, 5:26:39 PM10/20/18
to fltkg...@googlegroups.com
Thanks for the quick test and confirmation!

Albrecht

Anthony Nemoff

unread,
Oct 31, 2018, 11:52:12 AM10/31/18
to fltk.general
Hi!

Just wanted to chime in to say that we have been using the mentioned patch since February (2018) on multiple Windows platforms with different GPUs without issues.
I thought it would be helpful to you guys to have this feedback.

However, I haven't investigated further the issue since February.

Regards,
-Anthony
Reply all
Reply to author
Forward
0 new messages