I also removed the System.exit(1) calls in PiscesTileGenerator. It doesn't seem like a good idea to shut down the whole VM because of a rendering bug.
----- Original Message ----- > Hi Jim. > > > Forgive my ascii art shorthand, "=>" was supposed to be an arrow, > > not > > a > > comparison operator. I was saying that you use the word "and" on > > that > > line and it should be changed to the word "or" because a > > non-compliant > > edge can be invalid by violating either (i.e. "or") condition. In > > other > > words/symbols: > > > > "and" ===should be===>>>> "or" > > Aha, I see. I usually use "==>" for implication. > > > Also, in rereading it, you talk about the edges crossing outside of > > the > > range but my brain immediately goes to the fact that when they first > > came in they may have had huge extents, but they were then clipped. > > Perhaps it would be better to use the term "edge fragment stored in > > the > > edges array" or "clipped edge". Also, the word "cross" is a little > > overloaded. What about: > > > > // Preconditions: Only subpixel scanlines in the range > > // (start <= subpixel_y <= end) will be evaluated. No > > // edge may have a valid (i.e. inside the supplied clip) > > // crossing that would be generated outside that range. > > I do like this better. > > > Just curious if the "final" attribute on local variables might be > > causing it problems? > > No, I don't think so. What's happening is that the compiler is trying > to unswitch the loop by moving one of the switch statements outside > of the loop. Once it does that, the IR graph ends up with many code > paths, and in one of them, a variable that is used for a future > array index is set to a value that makes the index always < 0. > When int to long conversion nodes are created are created by the > parser, we give the node a type of int[0,max_int]. So, when the > index is proven to be <0, that node is killed. However, the control > path that leads to that node's computation is not killed (in this > case, that's because it's an OSR compilation and it doesn't have > enough information to prove it's dead code). So we end up with a > phi node with a control input whose corresponding data input is > dead, and this causes problems in some future dominator computations. > The workaround fixes it by doing the loop unswitching manually. > > > I guess I meant the spmin/maxY. The pmin/maxY have been rounded out > > to > > the next full pixel boundary and then you convert back to sub-pixel > > precision, but in doing so you then force the iterator to iterate > > through any subpixel positions before spminY and after spmaxY. This > > is > > probably in the noise for any but the smallest shapes, but still - > > isn't > > it wasted effort? > > Good point. I completely forgot we had the spm* variables. > > I updated the webrev. > > Regards, > Denis. > > ----- Original Message ----- > > Hi Denis, > > > ...
