Bugzilla – Full Text Bug Listing
| Summary: | [BugSur] Control#fillBackground() with background image results wrong pattern start location | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jeeeyul Lee <jeeeyul> | ||||||||
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> | ||||||||
| Status: | NEW --- | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | peter, sravankumarl | ||||||||
| Version: | 4.18 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | Macintosh | ||||||||||
| OS: | Mac OS X | ||||||||||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=569168 | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 284921 [details]
file to reproduce problem
Control#update(): 1324 context.setPatternPhase(phase); seems not work properly for specific case. I found these: * This problem occurs when there are some SWT.BORDER flagged controls in the same shell. * This problem also occurs when there are some NSScrollable controls in the same shell Another related bug 569168. Looks like root cause same for both. (In reply to Sravan Kumar Lakkimsetti from comment #3) > Another related bug 569168. Looks like root cause same for both. I agree. I have a theory about this, I will mention about it after more digging tomorrow. Sorry, I have failed to find useful clues. The office will be closed for the time being due to covid 19, I can't pursuit this problem for while. Please somebody else pull this excalibur out instead. I found these things: Consider that situation: Shell +- A +- B +- C (has an NSSCrollView due to SWT.X_SCROLL or SWT.BORDER) +- D +- E 1. Background patterns of D, E are rendered properly. (after scrollview) 2. Background patterns of A, B, C are rendered incorrectly. 3. Painting A, B, C seems to use a not flipped coordinate system. when I add below code on Control#fillBackground():1324 phase.x -= tx; phase.y += ty; phase.y = controlView.bounds().height; // <- I've added this line context.setPatternPhase(phase); These small change just ignore the coordinate system of the window content view. And it assumes that those view has it's own buffers and own drawing context. Then interestingly A, B C are rendered properly. However NSView.isFlipped() always returns true. And it is not just control's background problem. Painting image patterns using GC facing same problem. See GC.setPatternPhase() Created attachment 284987 [details]
Example code about the above comment (ABCDE thing)
(In reply to Jeeeyul Lee from comment #6) > phase.y = controlView.bounds().height; // <- I've added this line There was a typo, It was actually likes that: controlView.frame().height - imgHeight; I will investigate this tomorrow after 4.18 release is almost complete (In reply to Jeeeyul Lee from comment #8) > (In reply to Jeeeyul Lee from comment #6) > > phase.y = controlView.bounds().height; // <- I've added this line > > There was a typo, It was actually likes that: > controlView.frame().height - imgHeight; When I tried this the problem moved from top three to bottom two. Adding this line fixes A,B and C images but breaks D and E |
Created attachment 284920 [details] wrong-pattern-offset [BugSur] Control#fillBackground() with background image results wrong pattern start location. See the Attachment: * Expected result: Red to Blue gradient. * Actual Result: The pattern offset seems to be wrong.