138.68 KB, image/jpeg
176.75 KB, image/jpeg
182.24 KB, image/jpeg
170.23 KB, image/jpeg
189.18 KB, image/jpeg
31.45 KB, image/jpeg
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
Created attachment 92908 [details] just big enough to break the rendering 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
Created attachment 92909 [details] lots of unrendered area, but line wrapping works as if it rendered. 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?
Created attachment 93157 [details] Mozilla renders correctly when Chimera doe not. 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
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.
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...
Created attachment 150310 [details] Vertical blocks of pinstripe appear in scrolling of a wide image 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
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.