173587 - Allow limiting of colormap (similar to 4.x's -ncols option)

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[Wolf]

Solaris needs a command-line option to limit the number of colors used by
the browser, to prevent colormap flashing.  For an example, older Netscape
versions such as 4.78 supported this.

Comment 1

[Matthias Versen [:Matti]]

no build ID given, could mark invalid but duping to bug 22337

Reporter:
Always add the build ID in a bug report and ALWAYWS search before you file a bug.

You will find 8 bug reports with the summary colormap.....


*** This bug has been marked as a duplicate of 22337 ***

Comment 2

[Wolf]

Matti -

Build ID: Mozilla 1.1 -- why is this not available in the submit 
screen's 'version' field?

--

Searching for 'colormap' yields only two open bugs for this current issue, 
which have nothing to do with this problem:

65881  nor  --  Sun  [e-mail]  ASSI   mozilla appears to be using two 
colormaps  
114929  nor  --  All  [e-mail]  NEW   gtk desktop icon should 
use the system default colormap, ...  

--

bug 22337 is ***NOT*** what I asked for.  My original request **specifically** 
noted the Netscape 4.78 color reduction option to "prevent colormap flashing", 
which the -install option causes to happen.  The similar option on Netscape 
4.78 is -ncols.  I'm on an 8 bit Solaris system, and Mozilla 1.1 seems to 
always install it's own colormap, whether or not -install is used.

Comment 3

[Roland Mainz]

The problem is that Mozilla's default Unix/Linux toolkit is GDK/GTK+-based -
which has very very limited support for non-TrueColor visuals.
Does anyone know how (or if) this bevaiour can be controlled at the
GDK/GTK+-level ?

Comment 4

[Reinout van Schouwen]

That should perhaps be asked on the gnome gtk-devel mailinglist. It's probably
best to wait for the gtk2-version of mozilla before trying to fix this.

The following gnome-bug might (or might not) be relevant:
http://bugzilla.gnome.org/show_bug.cgi?id=75497

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 173603 has been marked as a duplicate of this bug. ***

Comment 6

[James Rome]

I just installed Mozilla on my Ultra5. The solaris 2.7 2003090111 build.
Mozilla grabs the color map and turns everything else on the screen blue and
green. Only the mozilla window is visible
Clicking on another window makes mozilla invisible!

It works fine on a remote display. This just occurs at the console. I presume I
have a color card with limited colors, because the bitmaps on, say the modern
header are all speckled.

Comment 7

[Charles Slivkoff]

This is not specific to Solaris, but is common to any X display limited to depth
8 PseudoColor. There are still a lot of legacy X displays (old X terminals, old
*nix workstations) and applications in use which assume depth 8 PseudoColor. I
agree that a private colormap helps, but without multiple LUTs, colormap
flashing occurs.

Comment 8

[Asa Dotzler [:asa]]

related to bug 98802 or bug 173587 ?

Comment 9

[Charles Slivkoff]

(In reply to comment #8)
> related to bug 98802

Not really. This bug is requesting a cap on color allocation: mozilla will
allocate no more than NCOLS colors (in whatever visual was selected).

> or bug 173587 ?

This is 173587.

Comment 10

[Greg Ubben]

It looks to me like the relevant GTK bug is
http://bugzilla.gnome.org/show_bug.cgi?id=99276
"missing API: gdk_rgb_set_max_colors()"

Comment 11

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 12

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 13

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 14

[Jeff Muizelaar [:jrmuizel]]

We don't support non 24 bit color anymore.