Last Comment Bug 322376 - Large coordinates cause missing canvas paths (cairo fixed-point path issues)
: Large coordinates cause missing canvas paths (cairo fixed-point path issues)
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Canvas: 2D (show other bugs)
: Trunk
: All All
-- normal (vote)
: mozilla1.9alpha8
Assigned To: Vladimir Vukicevic [:vlad] [:vladv]
:
: Milan Sreckovic [:milan]
Mentors:
Depends on: 384681
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-04 10:34 PST by :Gijs
Modified: 2009-11-23 09:03 PST (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase (1.02 KB, text/html)
2006-01-04 10:35 PST, :Gijs
no flags Details
better testcase (965 bytes, text/html)
2006-04-19 15:29 PDT, Vladimir Vukicevic [:vlad] [:vladv]
no flags Details

Description User image :Gijs 2006-01-04 10:34:52 PST
Steps to reproduce:
[Testcase attached in a bit, listing js here doesn't make sense]

Actual results:
Empty canvas

Expected results:
Big green line

You can see a big green line if you change the last lineTo call to a moveTo call instead, or make the coordinates smaller.

I'm setting severity normal because I don't know if many people will experience this. I have a problem with it because I'm making an extension to render math functions, and I didn't exactly expect to have to implement my own magic not to display items outside the viewport...

Note that in this case, the coordinate number used is rather large. It *seems* that as a path has more nodes, the size of the coordinate number required to make the path vanish decreases.

I'm wondering if a keyword 'dataloss' is appropriate here or not. I'm not experienced in filing Core bugs, if someone else (more experienced than me in the subject at hand) thinks it is, please add it.

db48x reproduced this on linux with trunk from 'a day or two ago'. Marking Platform/OS all. Maybe this is a cairo problem?
Comment 1 User image :Gijs 2006-01-04 10:35:37 PST
Created attachment 207517 [details]
Testcase
Comment 2 User image :Gijs 2006-01-04 10:39:53 PST
eh. Linux reproduction build used was

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051220 Firefox/1.6a1


I reproduced on a Windows 1.5 release build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

and current trunk:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060104 Firefox/1.6a1
Comment 4 User image Vladimir Vukicevic [:vlad] [:vladv] 2006-04-19 15:29:41 PDT
Created attachment 219075 [details]
better testcase

Better testcase; the problem is that coordinates that are too large I think overflow the 16.16 internals inside cairo, and cause segments to not get rendered.
Comment 5 User image :Gijs 2006-11-27 06:07:02 PST
Vlad: so if this is a Cairo problem, do 'we' have anything to fix and/or does a new version of Cairo (plan to) fix this problem?

FWIW, still broken on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061121 Minefield/3.0a1
But I suppose that's sorta expected...
Comment 6 User image Vladimir Vukicevic [:vlad] [:vladv] 2006-11-27 11:15:55 PST
It's nothing that we can really fix; there is some upstream cairo work going on in this area, but noone's tackled this yet.  Chances are that it probably won't get fixed anytime soon though, but we'll see.
Comment 7 User image Vladimir Vukicevic [:vlad] [:vladv] 2007-12-04 15:21:46 PST
Fixed by bug 384681, at least getting us to 24.8.
Comment 8 User image :Gijs 2009-11-23 09:03:30 PST
(In reply to comment #7)
> Fixed by bug 384681, at least getting us to 24.8.

So my testcase now works, but yours doesn't... (3.5.5) What am I missing? :-)

Note You need to log in before you can comment on or make changes to this bug.