Closed Bug 4762 Opened 26 years ago Closed 25 years ago

Apprunner displays poorly on 8-bit displays (Linux only)

Categories

(SeaMonkey :: General, defect, P3)

x86
Linux

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: cpratt, Assigned: german)

References

Details

(Keywords: platform-parity)

Attachments

(4 files)

My linux box is only capable of displaying 256 colors on the screen due to
hardware limitations. When I start Communicator or Navigator 4.07, they look
like any other applications and the window manager looks okay too. However, when
I start apprunner, everything else turns all kinds of wiggy colors (black,
purple, etc.), and the apprunner window can have graphic problems as well (for
example, the menu and title bars turn dark blue and purple). This has never
worked for me. Phillip Bond sez it has something to do with using a private
color map...?
Assignee: don → michaelp
Component: XPApps → Compositor
Assignee: michaelp → ramiro
Target Milestone: M7
this is the expected behavior on low depth displays.

you probably are running kde and communicator, which are both color hogs.

try a very simple window manager setup with no icons or colors and no programs
running.

if you still get the color problems, then yes, maybe there is an issue.

in any case, i dont expect to look at this bug till much later.

marking m7
I think everything is about as simple as it gets - I'm using fvwm (yuck) and not
KDE, and I'm not running Communicator when I launch apprunner. I understand this
isn't high priority right now  - but there is definitely a problem on low-end
systems such as mine.
Summary: Apprunner displays poorly on 8-bit displays (Linux only) → [PP]Apprunner displays poorly on 8-bit displays (Linux only)
Status: NEW → ASSIGNED
Target Milestone: M7 → M9
ok. thanks for the info.

i still cant get to this till much later cause of all the other doomness...

marking assigned m9.
Severity: minor → normal
Component: Compositor → Apprunner
Moving all Apprunner bugs past and present to Other component temporarily whilst
don and I set correct component.  Apprunner component will be deleted/retired
shortly.
Assignee: ramiro → german
Status: ASSIGNED → NEW
Attached image 8bit screenshot (deleted) β€”
probably need to stay inside the 216 color palette... gramps said you should
look at this bug first and if you don't want it send it back to him
Assignee: german → don
yes, i dont want this bug.  reassign to don.
Assignee: don → german
i screwed up, back to german.
Didn't I fix this a while back? There are preferences settings I added that can
be used to control this.

Added mcafee to cc list; he has a bug like this. The bug I filed and fixed was
8413. Perhaps we need to document more clearly in release notes how this works
(see 8413 for instructions).
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → LATER
The icons will eventually fully comply to the web-safe palette ( I thought they
already are, so I ma not sure why they are showing up weird on the screenshot
supplied earlier). Wrt to the background colors, those are specifically create
to detect problems before beta with regards to hardcoding to grey where icons
have flaws in their transparency and XUL elements have grey hard-coded in their
css files. This and the fact that any web-safe color outside grey (#CCCCCC)
would be too glaring for day to day use. Hence #CCCCDD for now. This will be
fixed for beta one, but we should seriously think whether those poor souls on
low-powered Linux displays should be treated as an edge case,one that we fix
other than making everybody else suffer from the lowest common denominator. (By
supplying an extra xul.css for those case, it's just some lines that define
color that would change)
Status: RESOLVED → VERIFIED
Status: VERIFIED → REOPENED
There's a whole class of 8-bit solaris displays
that should not be considered edge cases.
Reopening.
I also fail to understand why a bug that "should be fixed for beta 1"
got ? LATERED.  Later is for "fix this in 6.0".
Status: REOPENED → ASSIGNED
Target Milestone: M9 → M12
good points on solaris. will reconsider.
my fault for setting later, I meant to set to m12 (just before beta 1)
Target Milestone: M12 → M17
Resolution: LATER → ---
This needs to be fixed before we can use any new UI.  If the UI is going to look
like crap on 8bit displays then someone didn't put much thought into the UI.
This needs to be fixed by the time a new UI lands.
Component: other → UE/UI
UE/UI
the new and look feel (to come in shortly) will use colors from the web palette
to make this work. Stay tuned.
QA Contact: beppe → claudius
Keywords: pp
Summary: [PP]Apprunner displays poorly on 8-bit displays (Linux only) → Apprunner displays poorly on 8-bit displays (Linux only)
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
Blocks: 28883
can you illustrate by including some screen grabs?
Attached image 8-bit screenshot (2000022308) (deleted) β€”
Blocks: 29137
No longer blocks: 28883
For the latest screen shot, maybe I have eye problemes ;-) but it looks as 
normal as we saw today on Window's. Do we consider this bug is fix? or the 
problem is still there?
Looking at the screen shot, I really think that is the best we are going to be
able to do. Clearly we are getting the colormap, visual right. To me the UI
looks as good as it does on deeper displays, given limitations of 8-bit. About
the only defect I see is some dithering in the conent which is unavoidable.
Closing.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago25 years ago
Resolution: --- → FIXED
agreed, this looks pretty good for me.
Another bug has been filed for non-imglib rendered
icons (desktop, etc.): http://bugzilla.mozilla.org/show_bug.cgi?id=28369
marking VERIFIED
Status: RESOLVED → VERIFIED
This is a _really_ minor point but if you look above the Mozilla M up at the top
right of the the second screenshot you can see the grey has been dithered. Why
not make it the same grey as the grey to the left/right/below the M so it
doesn't dither?

Also, input boxes look ugly in 8-bit because they are missing the bottom grey.
Severity: normal → minor
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Attached image 8-bit screenshot (2000050208) (deleted) β€”
Upon looking at a screenshot from a newer build, it appears that the dithering
above the button has been fixed. However, the bottoms of certain widgets do not
appear... (see new screenshot).
sitsofe, i think your issues need to be reported as new and different bugs. This bug should be reverted back to it's verified status.
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Latest build on 5/5 hasn't done anything for me as far as psych dithering. I
don't know if this is normal or what. I am running Mozilla on OpenBSD from my
Linux box and the dithering for the interface and pictures on pages is not close
to the quality of Netscape 4.x 
Hmm. Should I put this as a separate bug?
Attached image 8-bit rendering on OpenBSD from a linux box (deleted) β€”
Marking VERIFIED this bug should not have ever been reopened. IF you have issues, file NEW, very specific bugs.
Status: RESOLVED → VERIFIED
Split 8-bit form element display into bug 39250.
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: