Rotation in V10?

Russ · March 2, 2020, 5:34pm

I’m not sure I follow. Are you saying that we would have to update to V12 and migrate to WPF to use the WPF solution? As much as they want rotation, I just don’t see them authorizing the resources to migrate to WPF.

As for a similar WinForm solution, that should be easy. Just draw everything on a temporary DC (Drawing Context) or other non-display buffer (bitmap etc.), rotate as required, and finally bitblt it to the display context. You just have to make sure the background of the display is consistent so you don’t see the framing of the rotation. This is a very common way to speed up complex drawing, and I would be surprised if you aren’t already doing that. And of course you have to transform user interactions (clicks, hot tracking) to figure out what they are interacting with.

Ethan · March 3, 2020, 7:57am

Hi Russ,

That’s double buffering, and we keep using it in our product to prevent flicker. But because some reason we cannot make the Winforms works the same like WPF did.

In fact our developer is keep working on solve the cutting issue when rotate, any update I will let you know.

Regards,

Ethan

Ethan · March 9, 2020, 8:32am

Hi Russ,

Please upgrade your packages to latest pre-release version, our developer had solved the rotate cutting issue.

And the vector layer match raster layer problem had get some enhanced, because different render logic for vector layer and raster layer, we cannot make sure each pixel match when rotate them, so it should be the best result till now. But our developer won’t stop optimize it.

Regards,

Ethan

Russ · March 9, 2020, 3:13pm

Thank you for updating me, and him for the fix.

Without the ability to keep shape files aligned, this is a non-starter for us anyway. I’ve got a number of other irons in the fire, so I’m not sure when or if I will get around to trying the partial fix. Hopefully a full fix will be available soon and I can just get it all done with one update.

Ethan · March 10, 2020, 6:31am

Hi Russ,

In our test sample, the offset is only one pixel and it only appear in very special angle.

Because one type layer can be drawn in half pixel but the other cannot, we hadn’t found a solution to make them totally match in each scenario. Could you please try the latest package and see whether it works in your scenario?

Regards,

Ethan

Russ · March 10, 2020, 7:17pm

If it’s only one pixel, and it doesn’t keep offsetting more and more, then it should be ok for our needs. But the sample you sent earlier got offset by WAY more than one pixel at a particular angle. So unless there has been a fix there, it won’t help.

So my next question is, what version? The latest I see for ThinkGeo.MapSuite and related is 11.0.0-beta128. But many other parts are at max of 10.6.0. Just guessing, I updated your sample project 8619 to those versions. As far as I can see based on that update, NOTHING has improved. It still clips to square at 90*, and zooming with rotation completely screws up the view port.

This is an example I got within 10 seconds of running the updated sample. All I did was rotate a few clicks, zoom out, rotate a few clicks, zoom in, there’s your image. And that’s your image not even updated with a shape file to test. Are they even testing this stuff? Or is there something else I need to do to see the changes?

And finally, please forward a sample that includes a shape file that you have tested to confirm it works. That way I don’t have to guess at what NuGet projects to update to what, and it will at least be suitable for testing the 2 main feature problems reported (not just raster clipping). The way this is going, it’s wasting both our time when it remains this badly broken.

Ethan · March 11, 2020, 2:25am

Hi Russ,

Yes you’re right, I should uploaded a sample. Here is the udpated sample.

I render a red rectangle shape contains the raster image, you can see follow rotate the relative position changes but the offset is only about one pixel.

8619.zip (37.3 KB)

Regards,

Ethan

Russ · March 11, 2020, 6:09am

Thank you.

The only difference I see other than adding a InMemoryFeatureLayer is the NuGet dependency for ThinkGeoMapSuite 11.0.0-beta129. But the latest available publicly is beta128 as shown in the image below that I captured just this moment. To save me having to go looking, are there other changes?

The new sample does seem to be working with a very short test. But as shown, it doesn’t appear to be available for me to test in our product. It’s very late here, so I’ll look at it more tomorrow. Hopefully this is happening early enough for you to reply before I get to my desk in the morning. If you have a path forward, I’ll try to test with our product in the morning.

And also another update for NativeImage “16” that I don’t have access to in NuGet. As this image shows, I only have access to 15, and I expect that makes a difference.

Also adding a full list of the dependencies for my earlier update of your first sample project (that I posted earlier about not working). Not sure it matters, but just in case…

Ethan · March 11, 2020, 6:49am

Hi Russ,

In fact we upload version 16 five days ago:

I think that’s maybe related with your pacakge source, I am using this package source: https://api.nuget.org/v3/index.json

If you still cannot get latest package, you can also manual download it from page then unzip it and add reference in your project.

I hope that’s helpful.

Regards,

Ethan

Russ · March 11, 2020, 5:28pm

I’m using the same package source. It’s never been changed from the default. I was not aware of the manual option, thank you for pointing that out.

In any case, I was able to get it updated, and it does appear to be working now. Great news! Thank you to you and your dev!

I’ll get this into the hands of the interested parties. I’m sure they will be thrilled, but I know the next question is going to be, when can we get it in an official release? I know that will be fluid, but can you give me a rough idea when that might be? In the mean time, we’ll continue exploring these changes to hopefully make sure there aren’t any more hidden gremlins

Ethan · March 12, 2020, 5:57am

Hi Russ,

Thanks for your update.

Maybe your NuGet delay is the IDE plugin issue or package cache issue.

I am glad to hear that works for your scenario, we had moved the change into release branch.

Here is the package list, you can download target version and test it.

packages.zip (486 Bytes)

Any question please let us know.

Regards,

Ethan