Respected development company: Canvas throws exceptions
Respected development company: Canvas throws exceptions
For Arc(), ArcTo(), AngleArc(), Chord(), Pie(), PolyBezier(), PolyBezierTo().
CopyRect(), and BrushCopy() totally fail.
Support Reply (from the owner): "Yeah, we know bout that" "We can't implement all APIs."
There is a big difference between "can't" and "won't".
Converting Windows GDI calls is not rocket science. I know that. I have been it for 33 or so years (since the Windows 0.8 beta - 1986 ish?)
Forwarding a GDI bezier to some other API is total child's play.
Seriously, you have three points to send (and perhaps the previous point).
Almost ever display driver has a bezier function.
PolyBezier is just sending multiple Bezier curves.
No Bezier function? Use another kind of spine. No other kind of Spine? Use a polygon. No polygon? Use lines. No Lines, use pixels, no pixels? OK, thats workable, send ASCII art.
Point is, the support reply was total bullsh*t.
They may not be able to do simple graphic conversions, but the SDK should not throw an exceptionf or calling Canvas.Arc().
At best, they should issue a compiler warning: "We don't know how to draw a arc".
I wont say who it was, but it not hard to figure out (Just call Canvas.Chord() on your 3rd party canvas and see if your app crashes).
I am shocked, because it puts of doubt on a related canvas framework (that almost everyone uses).
CopyRect? That should work! This is not some fancy PDF lib where there may not be a 100% solution (hey, ours works).
This is a simple Canvas layer that forward calls. Most all Canvas implementations do that. Few actually render anything (ours can).
Seriously, I see postings about another Canvas developer that posts demo's of the pretty lines and shapes "they draw", then you look at support page and see "Please update we called the OS with the wrong call to draw a line".
They are not drawing anything! They just call the OS to do the drawing.
And they want me to be impressed with pretty lines and shapes "they draw".
Horse Hockey!
I should have titled this "Why Johnny can't draw".
We have respected development companies, producing TCanvas descendent, and they cant draw anything they can't forward (to something that can).
So what are you buying? A wrapper.
Need something really drawn? Contact me. I do that sort of thing (for real).
Joe
For Arc(), ArcTo(), AngleArc(), Chord(), Pie(), PolyBezier(), PolyBezierTo().
CopyRect(), and BrushCopy() totally fail.
Support Reply (from the owner): "Yeah, we know bout that" "We can't implement all APIs."
There is a big difference between "can't" and "won't".
Converting Windows GDI calls is not rocket science. I know that. I have been it for 33 or so years (since the Windows 0.8 beta - 1986 ish?)
Forwarding a GDI bezier to some other API is total child's play.
Seriously, you have three points to send (and perhaps the previous point).
Almost ever display driver has a bezier function.
PolyBezier is just sending multiple Bezier curves.
No Bezier function? Use another kind of spine. No other kind of Spine? Use a polygon. No polygon? Use lines. No Lines, use pixels, no pixels? OK, thats workable, send ASCII art.
Point is, the support reply was total bullsh*t.
They may not be able to do simple graphic conversions, but the SDK should not throw an exceptionf or calling Canvas.Arc().
At best, they should issue a compiler warning: "We don't know how to draw a arc".
I wont say who it was, but it not hard to figure out (Just call Canvas.Chord() on your 3rd party canvas and see if your app crashes).
I am shocked, because it puts of doubt on a related canvas framework (that almost everyone uses).
CopyRect? That should work! This is not some fancy PDF lib where there may not be a 100% solution (hey, ours works).
This is a simple Canvas layer that forward calls. Most all Canvas implementations do that. Few actually render anything (ours can).
Seriously, I see postings about another Canvas developer that posts demo's of the pretty lines and shapes "they draw", then you look at support page and see "Please update we called the OS with the wrong call to draw a line".
They are not drawing anything! They just call the OS to do the drawing.
And they want me to be impressed with pretty lines and shapes "they draw".
Horse Hockey!
I should have titled this "Why Johnny can't draw".
We have respected development companies, producing TCanvas descendent, and they cant draw anything they can't forward (to something that can).
So what are you buying? A wrapper.
Need something really drawn? Contact me. I do that sort of thing (for real).
Joe
How CopyRect can be implemented f.e. on Direct2D canvas?
ReplyDeleteAlexander Sviridenkov And also on macOS context for example ? There is no way even read pixels from it.
ReplyDeleteAlexander Sviridenkov - You do not mention if the Direct2D canvas type is the source, the destination, (or both).
ReplyDeleteA general discussion follows regarding the operation. If you need specifics on "how to", I am available for hire.
Providing that you can get read access from the source, and write access to the dest, the overall operation is handled by an equivalent StretchBlt() operation.
If the both the source and destination is a raster surface (a pixel based frame buffer), your good to go, using a StretchBlt() like operation.
If the source or destination is not a raster surface (perhaps it is something different like a PDFCanvas or TMetafileCanvas), they would be need to first be rendered to a frame buffer surface (to operate with).
The StretchBlt() like operation would then transfer the appropriate pixels using the ROP code indicated by the "CopyMode" property between the source and destination frame buffers.
Aside from "if the source or destination are not raster based bufffers", temporary frame buffers buffers may needed, and the ultimate result of the StretchBlt() like operation may need to be transferred to the destination Canvas.
In some cases, the source, result, and or destination can be worked on directly (avoiding the use of temporary frame buffers).
In some cases, it may be adventitious to hand off some of the work to other technologies (such as a GPU).
I find (often enough) that simply moving memory to and from a GPU can sometimes take about as long as directly accessing the pixel memory to begin with (and you can provide the resulting operation at the same time). That said, depending on the source and destination (and operation), there may not be much (if any) gain in using a GPU in some situations.
Well there ya go.
Joe
Eugene Kryukov Not all canvas type are readable as pixels, so you do a best effort (as some CopyMode ROPS cannot be supported). I gave a good general working of CopyRect() in a reply to Alexander Sviridenkov - but in short, if you can emulate a StretchBlt() operation for a write, and you have any sort sort of source to read, you are mostly good to go.
ReplyDeleteIn regards to source TCanvas types, not all are readable. If you are the developer of such a source canvas, I would say that if you actually did the drawing to an internal framebuffer, that would solve the problem). Another workaround is to store a recording of the drawing primitives used (such as a Metafile), then play them to a frame buffer on read (or perhaps on a write if needed) to obtain a suitable pixel surface to work with for the CopyRect (and other like) operations.
It makes me remember about quickdraw in Inside Macintosh in the 80's
ReplyDeleteWhile, in general terms, I agree with Joe C. Hecht, I have to say that sometimes it's absolutely worth paying for "wrappers". WinSoft comes to mind that wraps a number of things for Android/iOS and they do this well, so all I need to do is to use it without having to fiddle.
ReplyDeleteAndrea Raimondi I agree with you. Winsoft is pretty good (and a good value), but I take issue with the PDF components. They claim to build PDFium, but a binary compare shows the DLLs to be the same un-vetted versions found scattered along Internet highway (and never seem to change or get updated). A high price for a wrapper (that is potentially very dangerous).
ReplyDelete