Hello.
Have you been able to take a look at this patch?
Regards,
Tore Halset.
On Mar 27, 2012, at 13:32 , Tore Halset wrote:
> Hello.
>
> Here is my current approach. It solve my problem and does not seem to use too much cpu power.
>
> For testing, I can recomend to switch out "JTS.createRectangle(gf, -XTHRESHOLD, -XTHRESHOLD, XTHRESHOLD, XTHRESHOLD)" with "JTS.createXYViewPolygon(gf, this, 100)" in the two GeoProj#forwardPoly-methods. It will take more cpu as more geometries fall outside of the clipping geometry, but on the other hand, Java2D will have less to draw.
>
> By switching "100" with "-100" you will easily see how the geometries are clipped.
>
> The patch also has a small fix for LatLonGCT. Removal of unneeded casts.
>
> Regards,
> - Tore.
>
> <om5-xthreshold.patch>
>
> On Mar 26, 2012, at 20:58 , Tore Halset wrote:
>
>> Hello.
>>
>> Thanks. Yes, this is all in pixel space. I will have to do some more testing before sending in a patch.
>>
>> Regards,
>> - Tore.
>>
>> On 26. mars 2012, at 17:04, Don Dietrick wrote:
>>
>>> The code that OpenMap has for intersections is in the com.bbn.openmap.geo package, and that code works in lat/lon space on the Geoid. It's not something you'd want to use for any OMGraphic and general clipping, since it would be a lot of extra work and processing.
>>>
>>> The last time I looked at JTS it only worked in pixel space, so to be accurate you should really only use it on the projected coordinates or on the generated Shapes inside the OMGraphics. That does sound like something that could be integrated into the projection classes, though, to get accurate clipping for large projected shapes. It could be inserted where the threshold code is now, I'd have to look at the JTS Geometry#Intersection API to understand the specifics of what would be required.
>>>
>>> Thanks, JTS is a good suggestion for this,
>>>
>>> - Don
>>>
>>> =-=-=-=-=-=-=-=-=
>>> Don Dietrick
>>> _at_dfdietrick
>>> =-=-=-=-=-=-=-=-=
>>>
>>> On Monday, March 26, 2012 at 10:45 AM, Tore Halset wrote:
>>>
>>>> Hello.
>>>>
>>>> I have a solution that seem to work fine, however it is using JTS intersection to clip the geometries without altering the angles. Does OpenMap already have something similar to JTS Geometry#intersection? I am uncertain on how this can be included in standard OpenMap.
>>>>
>>>> Regards,
>>>> - Tore.
>>>>
>>>> On Mar 3, 2012, at 04:52 , Don Dietrick wrote:
>>>>
>>>>> Hi Tore,
>>>>>
>>>>> Yeah, the clipping algorithm is hackish and old. I'll have to think about how to improve it efficiently, and more importantly, correctly. There are a lot of weird cases.
>>>>>
>>>>> - Don
>>>>>
>>>>> On Mar 2, 2012, at 9:50 AM, Tore Halset wrote:
>>>>>
>>>>>> Hello.
>>>>>>
>>>>>> By disabling the XTHRESHOLD stuff, I got in to a Java 2D hang as I render lots of images in parallelle.
>>>>>>
>>>>>> at sun.dc.pr.PathDasher.appendLine(Native Method)
>>>>>> at sun.dc.pr.Rasterizer.appendLine(Rasterizer.java:462)
>>>>>> at sun.java2d.pipe.DuctusRenderer.createShapeRasterizer(DuctusRenderer.java:495)
>>>>>> at sun.java2d.pipe.DuctusShapeRenderer.renderPath(DuctusShapeRenderer.java:97)
>>>>>> at sun.java2d.pipe.DuctusShapeRenderer.draw(DuctusShapeRenderer.java:46)
>>>>>> at sun.java2d.pipe.PixelToParallelogramConverter.draw(PixelToParallelogramConverter.java:130)
>>>>>> at sun.java2d.SunGraphics2D.draw(SunGraphics2D.java:2618)
>>>>>>
>>>>>> It looks like I still need to clip things that is far out of the view, but without changing the angle of lines. Here is the relevant part of GeoProj#forwardPoly.
>>>>>>
>>>>>> if (Environment.doingXWindowsWorkaround && (scale <= XSCALE_THRESHOLD)) {
>>>>>> int i, j, size = stuff.size();
>>>>>> float[] xpts, ypts;
>>>>>> for (i = 0; i < size; i += 2) {
>>>>>> xpts = stuff.get(i);
>>>>>> ypts = stuff.get(i + 1);
>>>>>> for (j = 0; j < xpts.length; j++) {
>>>>>> if (xpts[j] <= -XTHRESHOLD) {
>>>>>> xpts[j] = -XTHRESHOLD;
>>>>>> } else if (xpts[j] >= XTHRESHOLD) {
>>>>>> xpts[j] = XTHRESHOLD;
>>>>>> }
>>>>>> if (ypts[j] <= -XTHRESHOLD) {
>>>>>> ypts[j] = -XTHRESHOLD;
>>>>>> } else if (ypts[j] >= XTHRESHOLD) {
>>>>>> ypts[j] = XTHRESHOLD;
>>>>>> }
>>>>>> }
>>>>>> stuff.set(i, xpts);
>>>>>> stuff.set(i + 1, ypts);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> - Tore.
>>>>>>
>>>>>> On Mar 2, 2012, at 12:29 , Tore Halset wrote:
>>>>>>
>>>>>>> Hello.
>>>>>>>
>>>>>>> I have a OMLine between two lat/lon points. When the user zoom very far in to a part of the line, the line suddenly changes its angle.
>>>>>>>
>>>>>>> The cause of this strange behaviour is in GeoProj#forwardPoly that adjust screen coordinates outside of XTHRESHOLD with value 16384.
>>>>>>>
>>>>>>> This is controlled by the Environment.doingXWindowsWorkaround parameter. For Linux and OS X, this seem to be code from svn revision 980 dating back to late 2003. Perhaps this could be removed now?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Tore Halset.
>>>>>>>
>>>>>>> --
>>>>>>> [To unsubscribe to this list send an email to "majdart_at_bbn.com"
>>>>>>> with the following text in the BODY of the message "unsubscribe openmap-users"]
>>>>>>
>>>>>> --
>>>>>> [To unsubscribe to this list send an email to "majdart_at_bbn.com"
>>>>>> with the following text in the BODY of the message "unsubscribe openmap-users"]
>>>>>
>>>>> --
>>>>> [To unsubscribe to this list send an email to "majdart_at_bbn.com"
>>>>> with the following text in the BODY of the message "unsubscribe openmap-users"]
>>>
>>
>> --
>> [To unsubscribe to this list send an email to "majdart_at_bbn.com"
>> with the following text in the BODY of the message "unsubscribe openmap-users"]
>>
>
--
[To unsubscribe to this list send an email to "majdart_at_bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]
Received on Tue Apr 10 2012 - 02:39:40 EDT