Closed Bug 22337 Opened 24 years ago Closed 22 years ago

Possible to install colormap on 8 bit displays?

Categories

(Core Graveyard :: Image: Painting, enhancement, P3)

Product:
Core Graveyard
Component:
Image: Painting
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: reidr, Assigned: pavlov)

References

Details

(Keywords: platform-parity)

Attachments

(1 file, 1 obsolete file)

"--install" -> "-install" for strict 4.x parity
3.34 KB, patch
pavlov
: review+
tor
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
I'm stuck on an 8 bit Sun display, so I use Netscape 4.x's -install flag to have
Netscape install its own colormap.  It looks much better that way than a reduced
number of colors (and impacts other apps less), and I can tolerate the
flashing.  Does Mozilla have such a capability, and if not, could it be added?
Thanks.
Assignee: nobody → pnunn
Component: Browser-General → ImageLib
QA Contact: nobody → elig
Sounds like a pnunn thing...
Status: NEW → ASSIGNED
Target Milestone: M15
Sounds like a good option.
-pn
Moving to m20
Target Milestone: M15 → M20
Target Milestone: M20 → Future
Severity: minor → enhancement
I disagree that this bug's severity should have been changed to "enhancement". I
work for an organisation that has a large number of HP workstations with 8-bit
PsuedoColour displays, and many of our applications are unusable if they can't
allocate pens.

Netscape has always had this option. Any X application that uses a lot of
colours and cannot install its own colour map is *entirely useless* to us. We
will simply be unable to run it. Upgrading our systems is not an option, and I
really don't want to be stuck on Netscape 4 for ever.

I'm quite surprised I'm the only person voting for this bug.

Are you volunteering to fix the bug?

I think the fix is pretty straightforward - a call to gdk_rgb_set_install(TRUE)
early in the startup sequence.  The trick is doing this in a clean way without
introducing a hard dependency between mozilla and gtk.

I agree with Stuart Sharp that this is more than an enhancement - it is critical
to have this functionality to make Mozilla useable in a low-colour environment.
I'm sitting at a Sun with an 8-bit card...

Netscape's '-install' flag would be sufficient but IE on Solaris does a better
job by autosensing when it needs to install a colormap.

This also has knock on effects with plugins etc - Netscape does not handle this
correctly resulting in (for example) Netscape using its own colormap and an
embedded Java 2 applet using the default colormap... Therfor it is not as simple
as tor believes...
Blocks: 61530
QA Contact: elig → tpreston
Umm. This looks very similar to bug #22058
. In all that time, nobody has noticed?

The reporter on bug 65881 commented on how to modify the colormap preferences 
so that it uses the installed colormap:

From bug 65881:
I don't have a diff handy, but the change is trivial.  In
widget/src/gtk/nsAppShell.cpp, there is a function HandleColormapPrefs().  
Add

gdk_rgb_set_install( TRUE );
return;

at the top of the function.

The same effect can be had by changing modules/libpref/src/unix/unix.js
so that 
pref("browser.installcmap", true);

instead of the default false value.
Depends on: 65881
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Assignee: pnunn → pavlov
Status: ASSIGNED → NEW
I have many ultrasparc machines, all with 8bit displays, none of the default
skins, nor any at x.themes.org will render properly on an 8 bit display. As I
type this, I cannot hardly even tell where the scrollbars, buttons, or text
boxes, etc begin or end. Except for the icons, which have sucked all but 2 or 3
of my colors, all the widgets are rendered in either black or white. With the
forground, background, and some of the shadow details all rendered in white.Dont
even ask about how the webpages are rendered. At this point **lynx** handles
graphics better than mozilla on 8 bit displays.

I will be happy to provide screenshots.

Reporter, we have a new imaglib, would you get a recent build and let me know if 
this is still an issue and if so, please attach screenshots, thanks

I'm the original reporter, but I've since moved up to a 24 bit display, so the
whole thing became less important for me.  I could start my home Linux box in 8
bit color mode to test things, if that would help.  Gregg C, who posted a
comment earlier, sounds like a good person to run this by, too, since he has
lots of 8 bit Suns.

So, the following line needs to be added to prefs.js to install a colormap?

pref("browser.installcmap", true);

I assume it's not automatic?

About this screenshot. This is an ultra10 running solaris. The two mozilla
windows are from 2 different remote systems. The smaller window is from an
Ultra E1 running Debian GNU/Linux 2.2, running M18 (Mozilla  M18
Mozilla/5.0 X11; U; Linux 2.2.17 sparc64; en-US; m18 Gecko/20001113) (it
does not have a graphics card on it, it will become a dns server shortly. The
2nd is from an Dell PC also running Debian 2.2 (Mozilla/5.0 (X11; U; Linux
2.2.15 i686; en-US; m18) Gecko/20001103).

I added the color map option to both prefs files. It seemed to help somewhat,
but this is still unusable. I could deal with this at home, but these systems
are owned by my employer so I had to reinstall solaris on my test boxes.
Managers, etc would find this unacceptable. They do have a point, these are
not for surfing they are used as interfaces to systems controlling telco
equipment, which often display long pages of complex forms, and table output
with many rows of status indicators and links to change status, pull more info,
etc.

IMHO, all of this could be fixed with a skin, that has one shade of grey for
the forground of all the surfaces and widgets, then 2 or 3 other colors for
widget details, say black for lines and maybe a lighter or darker grey for
shadows or other details. Instead of color icons, just have grey buttons like
the ones you could use in netscape, when you selected "text only" for the
buttons in the edit preferences window. Also a low color mozilla animated icon
would really make it great. It's not just a seperate colormap, but even with all
8bit colors, the app had garbled areas, and it still effects the webpages. I
would think the colors mozilla uses for the interface and the rendered pages
would be shared, but from looking at these, I don't think that is how it works.
I could also provide images of netscape 4.x on the same display.

Unfortuneately I don't know how to make a skin, and I don't have time to
investigate how to do so right now. I have to attend some telephony training
classes while still working my normal duties. Which is why it has taken me so
long to follow up on this.

I'm about to download a recent nightly build to try out. I didn't see any for
sparc on linux, so I'll try and compile the source, but I've never tried it
before so I don't know how well that will go.

Anything I can help with, I will be glad pitch in.

*************

Wondering what screenshot I'm talking about. I don't know the best way to
distribute it, so I'll just post it on my box at home. I'll place it at
http://64.81.162.230/mozilla

Anyone interested in looking at it can.
Gregg C, that URL gives an error. Please attach your screenshot using the 
`Create a new attachment' link in Bugzilla.
Keywords: pp
The url, is correct, just add a / to the end or just leave out the mozilla part,
the root index.html has a link to
the image, otherwise it is just a blank place holder.

I can't seem to get network solutions to update my freaking DNS, so it
grinds......
A 2 or 3 color skin would help alot, an 8 bit display only has so many colors,
especially if mozilla is not the only app running, the display will look bad. I
personally don't like using seperate colormaps, but the option is good to have,
because in some circumstances that is the only thing practical. But even if the
webpages look bad because of few colors, then at *least* the netscape widgets,
forms and other graphical features should be visable and usable. That part
should be free of "weird colors" and garbage.

I could work on such a low color skin now, but I have not been able to find
anykind of howto to make them. If someone would point me in the right direction,
I could try, also a low color animated mozilla icon would help. I just want the
application to look simple, clean, and not flash when changing focus. It just
looks more professional that way. Except for the limited colors, the systems we
have are very usable systems. Now, these machines are outdated in pure CPU
power, but they are very stable with quality construction, some individual
machines have upwards of a year or 2 of uptime under solaris. If I can get these
running linux + mozilla then these boxes can serve their purpose for the next
decade or so.
*** Bug 93248 has been marked as a duplicate of this bug. ***
This bug still open ? No '-install' option after one
and a half(!!) year ? I can't believe this, since useable display 
in any colordepth is one of the basic principles of good
program design EVERY student on informatics learns in the 
very first semester (at least in good old europe) !!! 
Hey, quality supervisors, where are you ??? I would mark this 
as a BLOCKER (and would fire the programmers, if this had been
a software company..) !

Will this be fixed before 1.0?
I know it's only aesthetics, but it's ugly, ugly, ugly nevertheless.
Actually, this is a 4.x parity issue- I'd add the 4xp keyword if I could! (and
mozilla1.0 as well)
Keywords: 4xp, mozilla1.0
Blocks: 22058
This bug is a blocker for N6 internal deployment at Sun as default browser. Can
someone raise the priority of this bug to P2/major
looking...
I can modify the preference to install the colormap on Solaris, then
the browser act stable as they used to be even when xv is running.
But the problem to me is that the colormap has taken over the Solaris'
system colormap. But the xv would not. 
Anybody can help?
I found the browser.ncols and browser.installcmap settings
in $INSTALLDIR/defaults/pref/unix.js could overload themselves
in $HOME/.mozilla/...../prefs.js. So you have to change all 
of them or just delete the same setting lines in one file.
Unfortunatly, some people have told me the opposite concept
before.

And I donot know the appropriate ncols number on the 8 bit 
display. Can anybody tell me?
Hi,
Since this is common in many old style workstations, 
and there is the change to install netscape to a server,
could somebody told me the exact ncols and installcmap
settings in the unix.js file?

Could someone help?


I would concur that this is a showstopper issue for companies with lots of 8 bit
workstations. I have been trying to use 0.9.8, but too many sites are now using
color images for buttons and links. Besides being ugly, you cannot do any work
because you cannot see the buttons or links.

I have played with the ncols and installcmap preferences to no avail. In my
case, it's a HP C3000.

Please fix before 1.0
Philip, normally you should start Netscape6 before other
applications like staroffice, ns4, xv etc. Otherwise,
you should enable the installcmap setting:
have you try it in unix.js:
+++++++++++++++++++++++++++++++++++++++ 
In file: $INSTALL_DIR/defaults/pref/unix.js, 
Remove next two lines: 
pref("browser.ncols",0); 
pref("browser.installcmap", false ); 

Add one line: 
pref("browser.installcmap", true ); 
++++++++++++++++++++++++++++++++++++++++

Yes I have tried several combinations including the one Jim Song suggested,
which actually made it worse.

Starting mozilla first makes the colors better, but does not improve the the
quality into the "acceptable" range. Further it grabs enough color to make other
programs hard to use or abort.

Also starting it first is not always an option for everyone.

Please restore the original "netscape -install" capability.
Pre-approving for 1.0.

/be
Keywords: mozilla1.0 → mozilla1.0+
The prefs weren't working because of a bug in the logic and the user prefs
haven't been read at the time the appshell is created.	This patch does
away with the prefs and adds a "--install" command line option for
installing a private colormap.
Comment on attachment 79858 [details] [diff] [review]
add a "--install" private colormap option

looks good, but --install is too overloaded; how about --install-cmap or
--installcmap as the option name?  Fix that and sr=brendan@mozilla.org.

/be
Attachment #79858 - Flags: superreview+
Just a question: if this is a 4xp bug, doesn't the option need to have the same
name as it did in 4.x?  In that case, it would be --install...

I'm not sure if there's a policy on this, though.  If not, --install-cmap would
seem to be a lot more sensible.  (Or --install-colourmap!)


Sorry, I forgot that 4.x used --install, and 4xp is set on this bug.  I withdraw
the --install-cmap idea.

/be
Actually 4.x uses "-install".  Mozilla takes an odd mix of "--" and "-", so
I randomly picked the option used.  Anyone want to make a final decision as
to the right one?
Moving bugs to new Image: GFX component
Component: ImageLib → Image: GFX

        Attachment #79858 -
        Attachment is obsolete: true

    
  

        Attachment #81065 -
        Flags: review+

    
    

    
  
Comment on attachment 81065 [details] [diff] [review]
"--install" -> "-install" for strict 4.x parity

r=pavlov

    
    

    
  
Comment on attachment 81065 [details] [diff] [review]
"--install" -> "-install" for strict 4.x parity

Carrying forward brendan's sr (comment 32).

        Attachment #81065 -
        Flags: superreview+

    
    

    
  
Checked into trunk.

    
    

    
  
Comment on attachment 81065 [details] [diff] [review]
"--install" -> "-install" for strict 4.x parity

a=asa (on behalf of drivers) for checkin to the 1.0 branch

        Attachment #81065 -
        Flags: approval+

    
    

    
  
Checked into the 1.0 branch.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
    

    
  
Running on HPUX with 8-bit graphics adapter.  Visual defaults to "PseudoColor". 

When I launch Mozilla 1.0 RC3 without the "-install" option, colors look normal.
When I launch *with* the "-install" option, the colormap is trashed.  It looks
like  an application that has a private color map, but does not have focus.  The
colors in the application don't change as the app window gains focus, they stay
messed up. Mozilla is the only application running at the time.

This bug is marked resolved, so the code change itself must be working
everywhere else.  Any hints on how I might go about debugging this on HPUX?

    
    

    
  
I asked someone inside HP to try the latest nightly build (6/11/2002) of Mozilla
on his 8-bit adapter machine, and he got the same results as I did.

"when I tried running your new mozilla, this is what I saw:
The colors in its window were all wrong and they would not correct
themselves regardless of which window I clicked on.  I saw the colors
of another window (which uses a private colormap) change, which tells
me that mozilla had indeed created a new colormap, but it seems that
while it thought it was rendering with the colors of that colormap,
it was actually using the same pixels from the default colormap
which were wrong.  Also, when I opened a second mozilla window
(from the File->New->Navigator Window menu), it appears that both
mozilla windows were using the same single private colormap rather than
having one per window (as the old Netscape does)."

    
    

    
  
There are two parts to this problem: recognizing the "-install" option to make
gtk install a private colormap, and allocating windows which then use that map.
 This bug got closed when just the first of those two issues got fixed,
apparently.  The other half of the problem is still open in bug 65881 and I just
added comments to that bug, referencing this one, which gives the 2-line change
needed to get gdk to use the cmap allocated by gdk_rgb_set_install(TRUE) when
creating new windows.  This has proven good results on a few systems now, so I'm
not sure if the private colormap in Mozilla worked anywhere without this.

    
    

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

    
    

    
  
I was able to verify that this works under Linux.  We tested on a Red Hat 7.2 
system with an NCD HMX thin client (8-bit).

    
    

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

    
  
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.