Closed Bug 159552 Opened 22 years ago Closed 20 years ago

Viewable area limited by primary screen on two-screen systems

Categories

(Camino Graveyard :: Page Layout, defect)

Product:
Camino Graveyard
Component:
Page Layout
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
Camino0.9

People

(Reporter: brunosjunk, Assigned: sfraser_bugs)

References

Details

Attachments

(6 files)

this one works
138.68 KB, image/jpeg
Details
just big enough to break the rendering
176.75 KB, image/jpeg
Details
lots of unrendered area, but line wrapping works as if it rendered.
182.24 KB, image/jpeg
Details
Mozilla renders correctly when Chimera doe not.
170.23 KB, image/jpeg
Details
Shows DHTML elements correctly positioned over pinstriped area
189.18 KB, image/jpeg
Details
Vertical blocks of pinstripe appear in scrolling of a wide image
31.45 KB, image/jpeg
Details 
I've noticed a problem in chimera.  It has been a problem since back in the 2.x
when I first tried this app.  I decided to check back and see if the newer
version fixed it, and to my surprise it has not.  I guess I should have done my
part a long time ago and reported this bug.  So here goes...

I have included 3 screeb grabs.  They show a small window where everything is
rendered correctly. A big window where the rendered area stops and the "Mac
Pinstripe" fills the extra area.  And a bigger window where there is a large
amount of "Mac Pinstripe" but if you compare the two images you will notice that
the window width, including line wrapping, goes correctly, even though the
render area does not.  This is an annoying little bug for those of us would use
monitors with high (1600x1200) resolutions.  My sepecific setup is:

Ti PowerBook G4 400MHz
OS: Mac OS 10.1.5
Ram: 384 MB Ram
2nd display: 19" ViewSonic G90f - 1600x1200 @ 75
Attached image this one works — 
window area:   1025x611
rendered area: 1025x611
Comment on attachment 92906 [details]
this one works

window area:   1025x611
rendered area: 1025x611

##Machine##
Ti PowerBook G4 400MHz
OS: Mac OS 10.1.5
Ram: 384 MB Ram
LCD Display: 1152x768
2nd display: 19" ViewSonic G90f - 1600x1200 @ 75
window area:   1206x940
rendered area: 1152x768

##Machine##
Ti PowerBook G4 400MHz
OS: Mac OS 10.1.5
Ram: 384 MB Ram
LCD Display: 1152x768
2nd display: 19" ViewSonic G90f - 1600x1200 @ 75
window area:   1533x934
rendered area: 1152x768

##Machine##
Ti PowerBook G4 400MHz
OS: Mac OS 10.1.5
Ram: 384 MB Ram
LCD Display: 1152x768
2nd display: 19" ViewSonic G90f - 1600x1200 @ 75
***** Additional Observations *****

The maximum render area appears to be limited to the pixel deminsions of the
main display.  Meaning: When my Apple Bar is at the top of my LCD panel and its
resolution is 1152x768, then the max rendered area of a window on my 1600x1200
CRT Display is 1152x768.  When I change the resolution on the LCD to 800x600
(and relaunched Chimera), the max rendered area on the CRT was 800x600.  If I
make my CRT the main display (drag the Apple Bar to it in the Displays>Arrange
"System Preferences" Pane) then then I have no problems, because I do not exceed
the size of the main display.  This is not an acceptable permanent solution, but
it works for now.
Ah, a two-display bug. There are a few of these for Fizzilla, as well.

Bruno, does this also happen using Mozilla?
It appears that Mozilla is not affected in the same way as I have described
Chimera.  The image show Mozilla (in the background) rendering nearly an entire
1600x1200 window.  It shows Chimera failing to do so.  It also show my LCD
resolution, and the arrangement of my monitors. (Important to note that the
smaller display has the menubar at the top.  If the menubar is dragged to the
largest display, both Mozilla and Chimera work perfectly.)
sounds like broken back buffer determination code, although that should be
turned off in chimera, no?
Assignee: saari → pinkerton
Blocks: 147975
this is gfx's assumption. how did we fix this in mozilla?

cc'ing some gfx folk.
Status: NEW → ASSIGNED
Target Milestone: --- → Chimera0.5
I hope this is remotely relevant here...(nightly build! slot load iMac)
opened window to apple in 1024x768
changed to 800x600
went to Apple's store page
changed resolution back to 1024x768

if I resized the window bigger, about one sixth of screen along the right side
went blank.  

if I reloaded or went to another page, all was fine again.
Something else sorta similar:

open sidebar, pull far out
delete an item
blank white space appears along the right in the sidebar.


*** Bug 162135 has been marked as a duplicate of this bug. ***
Target Milestone: Chimera0.5 → Chimera0.6
*** Bug 162708 has been marked as a duplicate of this bug. ***
Target Milestone: Chimera0.6 → Chimera0.9
*** Bug 175768 has been marked as a duplicate of this bug. ***
*** Bug 179229 has been marked as a duplicate of this bug. ***
I think this is a pretty simple gfx fix.
*** Bug 179607 has been marked as a duplicate of this bug. ***
Summary: does not render the entire window area of large windows → Viewable area limited by primary screen on two-screen systems
*** Bug 181346 has been marked as a duplicate of this bug. ***
*** Bug 181349 has been marked as a duplicate of this bug. ***
*** Bug 182974 has been marked as a duplicate of this bug. ***
*** Bug 183479 has been marked as a duplicate of this bug. ***
*** Bug 186063 has been marked as a duplicate of this bug. ***
*** Bug 177727 has been marked as a duplicate of this bug. ***
*** Bug 186484 has been marked as a duplicate of this bug. ***
*** Bug 187551 has been marked as a duplicate of this bug. ***
Bruno, can you still reproduce this problem using a current nightly build?
I'm not Bruno but I tried anyway :-). On my TiBook 400 I still see the
"Pinstripe" Pattern on the bigger external screen (1280x1024) in the area which
is bigger than the internal main screen (1152x782).

Most interestingly CSS-Elements with position:fixed; bottom:0px; which stick to
the lower end of the window render correctly.

Martin Girschick is right on the money.  Still broken, but my homepage is now
maccentral.com  When I opened the browser the page loaded and I noticed that all
of the fixed pisition divs rendered correctly on top of the pinstriping. 
Resizing the window happens very smoothly, and the fixed elements slide
correctly.  very strange.  I will attach a screen shot.  (using Nightly Build
dated 4/2/03)
Should I take this, pink?
*** Bug 163906 has been marked as a duplicate of this bug. ***
by all means.
Assignee: pinkerton → sfraser
Status: ASSIGNED → NEW
This appears to be a bug in NSQuickDrawView, which is the basis for Camino's
rendering. NSQDView maintains a GrafPort, which has a PixMap that is the size of
the primary screen. So we can't paint anything bigger.
*** Bug 197612 has been marked as a duplicate of this bug. ***
This bug has similarities with Bug 203467.
*** Bug 185678 seems to be a duplicate of this bug. ***
*** Bug 185678 has been marked as a duplicate of this bug. ***
*** Bug 228105 has been marked as a duplicate of this bug. ***
Mike wrote more than a year ago that he'd cc some guys from Mozilla. Did he get
any feedback how they solved the issue? Question is whether mozilla uses
Quickdraw as well. I asked the programmer of the Shareware GraphicConverter
about that issue and he never had that problem. There is a sample code on the
developer site of Apple which uses the grafport but as I'm not a specific mac
developer I have no idea where to look...

Has anyone filed a bug about this with Apple?
yes, a bug has been filed with apple and they have ignored it. i asked them
about it at WWDC, they said they weren't aware of it. Smfr knows the number.

It's not a problem in mozilla because it's only a problem in NSQuickdrawView
which mozilla doesn't use.
Radar 3219015.
Asked devbugs about that, they reply was (as anticipated) a standard text:

> Thank you for contacting us regarding the status of Bug ID# 3219015. 

> At this time, there isn't any new information available for this issue. 
> I have checked with engineering and the issue is still being 
> investigated. 

How sure are you (the developers) that this is a real bug with Apple? If yes,
then we can try to send a few more enquiries on that bug and see, whether Apple
notices that.

Same thing applies to that nasty redraw bug under Panther. Does anyone know, how
the workflow on bugs with Apple works?
a little birdy told me this is currently slated for the release after next, so
we're talking at least 2 years.
For people how a desperate for a solution - there's a workaround. The primary
screen is the one containing the menubar so if you change that to the bigger
screen the bug is resolved immediatly. Just reload your browser window and the
pinstripes should be gone.

I wonder why some CSS-elements (which are border-relative) render correctly -
anyone an idea?

I guess this bug should be reproduceable with a modified version of Apples
sample code at
http://developer.apple.com/samplecode/Sample_Code/QuickTime/Basics/QTGraphicsImport.htm
but as I'm not a mac coder, I didn't find the correct lines to do it.

*** Bug 231988 has been marked as a duplicate of this bug. ***
Hello, I've noticed the same thing:

867 12" / 640MB RAM / 10.3.2 / 20" on the other end. When I use the Dual Head
(Only 1024x768 on my 12") It breaks after this resolution. It "cuts it off"
otherwise, it works great. 
*** Bug 234985 has been marked as a duplicate of this bug. ***
(In reply to comment #44)
> For people how a desperate for a solution - there's a workaround. The primary
> screen is the one containing the menubar so if you change that to the bigger
> screen the bug is resolved immediatly.

This is not really possible on a laptop.
(In reply to comment #48)
> This is not really possible on a laptop.

Correction: it is. Drag the menu bar to the other screen in the Displays pref
panel. Still annoying, though...
If an image is wider than the browser window (which is already wider than the
horizontal resolution) and then the image is zoomed to full size, the
horizontal scrolling will cause vertical blocks of pinstripe gray to appear in
the middle of the image. This is reproducible in Camino 0.8+ (2004060508).
Seems to be finally resolved in 10.3.5. At least I can't see the effect anymore.

Simon? If you reported the bug, I guess you'll get one of those "can you still
verify this" emails during the next weeks from Apple :-).
I'll confirm that 10.3.5 appears to no longer be affected by this bug. If it
makes any difference, I'm running Camino 0.8: 2004062308 on a 1.25 GHz G4
Powerbook (512 MB RAM.)
Works for me now (Mac OS X 10.3.5). Also works for Mike Pinkerton. Apple must
have slipped in a fix somewhere in the last few releases.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: