Viewable area limited by primary screen on two-screen systems

RESOLVED WORKSFORME

Status

Camino Graveyard
Page Layout
--
major
RESOLVED WORKSFORME
16 years ago
14 years ago

People

(Reporter: Bruno, Assigned: Simon Fraser)

Tracking

unspecified
Camino0.9
PowerPC
Mac OS X

Details

Attachments

(6 attachments)

(Reporter)

Description

16 years ago
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
(Reporter)

Comment 1

16 years ago
Created attachment 92906 [details]
this one works

window area:   1025x611
rendered area: 1025x611
(Reporter)

Comment 2

16 years ago
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
(Reporter)

Comment 3

16 years ago
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
(Reporter)

Comment 4

16 years ago
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
(Reporter)

Comment 5

16 years ago
***** 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.

Comment 6

16 years ago
Ah, a two-display bug. There are a few of these for Fizzilla, as well.

Bruno, does this also happen using Mozilla?
(Reporter)

Comment 7

16 years ago
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.)

Comment 8

16 years ago
sounds like broken back buffer determination code, although that should be
turned off in chimera, no?
Assignee: saari → pinkerton

Updated

16 years ago
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

Comment 10

16 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

16 years ago
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

Comment 14

16 years ago
*** Bug 175768 has been marked as a duplicate of this bug. ***

Comment 15

16 years ago
*** Bug 179229 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 16

15 years ago
I think this is a pretty simple gfx fix.
(Assignee)

Comment 17

15 years ago
*** Bug 179607 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

15 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

15 years ago
*** Bug 181346 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 19

15 years ago
*** Bug 181349 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 20

15 years ago
*** Bug 182974 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 21

15 years ago
*** Bug 183479 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 22

15 years ago
*** Bug 186063 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 23

15 years ago
*** Bug 177727 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 24

15 years ago
*** Bug 186484 has been marked as a duplicate of this bug. ***

Comment 25

15 years ago
*** Bug 187551 has been marked as a duplicate of this bug. ***

Comment 26

15 years ago
Bruno, can you still reproduce this problem using a current nightly build?

Comment 27

15 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

15 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

15 years ago
Created attachment 119291 [details]
Shows DHTML elements correctly positioned over pinstriped area
(Assignee)

Comment 30

15 years ago
Should I take this, pink?
(Assignee)

Comment 31

15 years ago
*** Bug 163906 has been marked as a duplicate of this bug. ***
by all means.
Assignee: pinkerton → sfraser
Status: ASSIGNED → NEW
(Assignee)

Comment 33

15 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

15 years ago
*** Bug 197612 has been marked as a duplicate of this bug. ***

Comment 35

15 years ago
This bug has similarities with Bug 203467.

Comment 36

15 years ago
*** Bug 185678 seems to be a duplicate of this bug. ***
*** Bug 185678 has been marked as a duplicate of this bug. ***

Comment 38

14 years ago
*** Bug 228105 has been marked as a duplicate of this bug. ***

Comment 39

14 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?
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

14 years ago
Radar 3219015.

Comment 42

14 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?
a little birdy told me this is currently slated for the release after next, so
we're talking at least 2 years.

Comment 44

14 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.
*** Bug 231988 has been marked as a duplicate of this bug. ***

Comment 46

14 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. 
*** Bug 234985 has been marked as a duplicate of this bug. ***

Comment 48

14 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

14 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

14 years ago
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).

Comment 51

14 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

14 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

14 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
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.