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)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
Camino0.9
People
(Reporter: brunosjunk, Assigned: sfraser_bugs)
References
Details
Attachments
(6 files)
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
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.)
Comment 8•22 years ago
|
||
sounds like broken back buffer determination code, although that should be turned off in chimera, no?
Assignee: saari → pinkerton
Comment 9•22 years ago
|
||
this is gfx's assumption. how did we fix this in mozilla? cc'ing some gfx folk.
Status: NEW → ASSIGNED
Target Milestone: --- → Chimera0.5
Comment 10•22 years ago
|
||
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.
Comment 11•22 years ago
|
||
Something else sorta similar: open sidebar, pull far out delete an item blank white space appears along the right in the sidebar.
Comment 12•22 years ago
|
||
*** Bug 162135 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Target Milestone: Chimera0.5 → Chimera0.6
Comment 13•22 years ago
|
||
*** Bug 162708 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Target Milestone: Chimera0.6 → Chimera0.9
Comment 14•22 years ago
|
||
*** Bug 175768 has been marked as a duplicate of this bug. ***
Comment 15•22 years ago
|
||
*** Bug 179229 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 16•22 years ago
|
||
I think this is a pretty simple gfx fix.
Assignee | ||
Comment 17•22 years ago
|
||
*** Bug 179607 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•22 years ago
|
Summary: does not render the entire window area of large windows → Viewable area limited by primary screen on two-screen systems
Assignee | ||
Comment 18•22 years ago
|
||
*** Bug 181346 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 19•22 years ago
|
||
*** Bug 181349 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 20•22 years ago
|
||
*** Bug 182974 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 21•22 years ago
|
||
*** Bug 183479 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 22•22 years ago
|
||
*** Bug 186063 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 23•22 years ago
|
||
*** Bug 177727 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 24•22 years ago
|
||
*** Bug 186484 has been marked as a duplicate of this bug. ***
Comment 25•22 years ago
|
||
*** Bug 187551 has been marked as a duplicate of this bug. ***
Comment 26•21 years ago
|
||
Bruno, can you still reproduce this problem using a current nightly build?
Comment 27•21 years ago
|
||
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.
Reporter | ||
Comment 28•21 years ago
|
||
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)
Reporter | ||
Comment 29•21 years ago
|
||
Assignee | ||
Comment 30•21 years ago
|
||
Should I take this, pink?
Assignee | ||
Comment 31•21 years ago
|
||
*** Bug 163906 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 33•21 years ago
|
||
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.
Assignee | ||
Comment 34•21 years ago
|
||
*** Bug 197612 has been marked as a duplicate of this bug. ***
Comment 35•21 years ago
|
||
This bug has similarities with Bug 203467.
Comment 36•21 years ago
|
||
*** Bug 185678 seems to be a duplicate of this bug. ***
Comment 37•21 years ago
|
||
*** Bug 185678 has been marked as a duplicate of this bug. ***
Comment 38•21 years ago
|
||
*** Bug 228105 has been marked as a duplicate of this bug. ***
Comment 39•21 years ago
|
||
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?
Comment 40•21 years ago
|
||
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.
Assignee | ||
Comment 41•21 years ago
|
||
Radar 3219015.
Comment 42•21 years ago
|
||
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?
Comment 43•21 years ago
|
||
a little birdy told me this is currently slated for the release after next, so we're talking at least 2 years.
Comment 44•21 years ago
|
||
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.
Comment 45•21 years ago
|
||
*** Bug 231988 has been marked as a duplicate of this bug. ***
Comment 46•21 years ago
|
||
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.
Comment 47•21 years ago
|
||
*** Bug 234985 has been marked as a duplicate of this bug. ***
Comment 48•20 years ago
|
||
(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.
Comment 49•20 years ago
|
||
(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...
Comment 50•20 years ago
|
||
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).
Comment 51•20 years ago
|
||
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 :-).
Comment 52•20 years ago
|
||
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.)
Comment 53•20 years ago
|
||
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.
Description
•