const image = new Graphics.Image(100,100, gfx -> {
... gfx drawing commands here ...
// or image.update(gfx->{...}); for that matter.
const color = image.colorAt(50,50);
if( color.A == 255 )
... fully opaque ...
I believe it can be used in Konva with minimal porting instead of their quite ugly code that involves creation of temporary <canvas>es (DOM elements) for such tasks.
Hey, buddy,
Have you finished the KonvaJS transformation?
I’m also looking for a canvas library to use some small games,or some functions similar to PS.
I see that Konva.js, Matter.js, Fabric.js and so on all need some adaptation work.
Hope more experts like you can enrich the js library.
If KonvaJS works well at sciter,please tell us.
Thansk.
I tried doing some minimal porting for KonvaJS in few days but failed.
So I don’t finish porting it.
For KonvaJS,
I think it’s needed to do some code refactor for HitCanvas instead of using <canvas>. But I haven’t thought about how to do it yet.
I’ll try again if I have free time.
hitTest( lx, ly ) {
if(!this.cacheBitmap) // bitmap cache
this.cacheBitmap = new Graphics.Image(this.w, this.h, gfx => {
this.draw(gfx,0,0); // renders this on the image surface
const clr = this.cacheBitmap.colorAt(lx,ly);
return clr.A > 0; // true if this is not completely transparent pixel
In principle that cacheBitmap can also be used to speed up drawing if the visual has complex content. So, it will be rasterized once and then rendered as a bitmap.
I am making one more attempt to implement putImageData/getImageData, but, in any case, that my approach above with bitmapCache will always be more performant.
UPDATE: no luck, that idea will not work either. I can do that for Skia (CPU rendering, slow), but not for Direct2D.
The <canvas> API is not GPU friendly by design. Unfortunately.
It appears as methods like putImageData/getImageData, globalCompositeOperation and some others cannot be implemented without pixels to be present on CPU side (and processed by CPU – slow, especially on modern high-DPI monitors).
I can implement putImageData, getImageData only in context of Image Graphics:
Graphics Contexts in Sciter
Really, these functions make sense only in context of bitmap image.
Neither Canvas Graphics, nor Paint Graphics are bitmap backed on CPU side. They should be thought as vector graphics – batches of drawing ops to be sent to GPU for rendering.
I'm trying to build a custom color picker.
I wanted to draw on a html canvas and then call getImageData() to retrieve the color under the mouse, but I just found this post and I understand this is not possible with Sciter.
I also understand there are other ways to do what i'm trying to do, using a Graphics.Image, but I've searched in the documentation and the examples and i can't get something to work.
I've tried document.getElementById(xxx).paintForeground(()=>{}) but I get "not a function" in Inspector console without any other detail.
Could someone please give a small piece of code (raw js, not Reactor) to draw a Graphics.Image object to a div or a canvas ? Then I will be able to call .colorAt() to retrieve the pixel color.
Thank you
https://gitlab.com/sciter-engine/sciter-js-sdk/-/blob/main/samples.sciter/image-generation-painting/image-draw.htm
Also, you can paint on element directly - without creation of canvas or image: https://gitlab.com/sciter-engine/sciter-js-sdk/-/blob/main/samples.sciter/immediate-mode-painting/particles-at-background.htm
Thank you.
What I don't understand is the link between a div (or span or whatever html element) and the Element entity.
From the documentation I understand that a div IS an Element
But then document.getElementById(xxx).paintForeground() should work and the console says "not a function".
There is something I don't catch here.
paintForeground is a property, like onclick.
These are so called callback properties that accept either function or null.
In your case you should assign your paint handler to that property:
document.getElementById(xxx).paintForeground = function(gfx) {
... do custom drawing here ...
thank you
I observe that Elem.paintForeground() is called each time the mouse moves over the Elem. But nothing else changes, only the mouse moving. So nothing is invalidated, and in my understanding there is no reason to redraw Elem.
Is it a normal behavior due to immediate painting ? (or am I wrong somewhere ?)
</html>
Usually Sciter initiates drawing when DOM or style changes on any element inside the window.
Specific of GPU rendering: window gets redrawn in full on any change inside it.
I agree, tested with this colored example and no repaint on mouse move, so it's on my side. Thank you
<script>
document.body.paintForeground = function(gfx) {
gfx.fillStyle = "orange"
gfx.fillRect(0, 0, 200, 200)
console.log("paint");
</script>
</head>
</body>
</html>
Select forum from the below and type your message in "Create New Topic " text box.
Note to login to the forum you shall use your user name, but not e-mail address.
QQ.COM and 163.COM email users:
please use other email addresses for registration. Seems like these mail servers reject emails from sciter’s domain.
