Web app drawing objects in a canvas

Hi -

I’m testing out Web apps, don’t have a license yet and new to the Web app, and I’m wanting to make a version of my desktop “drawing objects in a canvas” for it.

Well after making the changes needed for Web app version to get it to run, it turns out it is horrifically slow. So much its unusable.
I’m sure some slowness is expect compared to desktop but I need it to run much faster than it is.

Are there any web app examples of “drawing objects in a canvas” or can it even be done ?

I’m looking to have some popup menus where I can select an image (which would be come the object) and be able to move it around thats more or less it.

Thanks.

I’m not sure to understand exactly your goal but I’ll try to give you some directions.
Don’t try to develop the application like you do in a desktop environment.
To “draw” something that you can move interactively like dragging, you don’t need a canvas to paint over.
First take a look at the web drag&drop example projects.
Basically you need to drag and drop containers if the user need to move images interactively.
Using css styles you can use the browser to paint an image as the background of these containers: forget webimageview and anything like that.
Cascaded Style Sheet (css) are your best tools: they let you adapt the image to the container, transform and resize the container in many ways and do a lot of visual things that are simply impossible to do in code if your primary goal is performance.
You must think the browser just like a graphics coprocessor doing graphics manipulation and it can do these operations many times faster than your code running in the application.
css is the way to tell the browser what to do with images and containers.
Is not difficult at all but knowledge about css is required: many helpful online resources are available.

And don’t worry: Xojo can be used for this with great results.

Regards.

You are not going to be able port a desktop canvas to web canvas. The simple answer is that a desktop will easily handle mouse drag events. That’s simply not feasible on web app because of the way Xojo web apps work as most events are processed on the server. So the latency between the browser and server is awful in comparison to a desktop app.

I figured that might be the case. Bummer but not a big deal.

Thanks.

Eric, don’t listen at Bob.
It can be done, trust me.

[quote=415904:@Maurizio Rossi]Eric, don’t listen at Bob.
It can be done, trust me.[/quote]
If you have an idea, please provide some examples.

In the mean time, the reason for Bob’s statement is that the built-in canvas control requires a lot of round trip messages to the server to do things like drag and drop within the canvas. If, on the other hand, you are just drawing shapes and text and wanting to detect where a user is clicking, that is entirely possible.

I’m curious what the end goal is once you have loaded an image and then dragged it around. Can you give me a “real world example”?

Well the idea is you could create some scenarios, which you could have several objects on the canvas. Things like construction equipment, buildings, people, etc… There would be some other features (at least in the desktop version) like scaling and rotating, etc… Then when done the the layout of the “scenario” it could be saved so it could be loaded back up again.

Sort of similar to this -
http://www.realsoftwareblog.com/2012/10/drawing-objects-in-canvas-with-paint.html

Though my desktop version is somewhat different than this, the idea is similar.

When I ran my web app version from the IDE and it got loaded up in the browser, it took way to long after selecting an item from the popup menu to get it displayed on the canvas and then delay after clicking on the object and moving it around on the canvas was way too long and to sluggish.

Right. So the problem is that there’s distance between where you’re doing the drawing and the browser. Where the desktop is instantaneous, each round trip to the server could easily be 100ms. That’s just the fact of the internet.

Now, if you have experience with html, css and JavaScript, you could use the WebSDK to fashion your own.

[quote=415961:@Greg O’Lone]Right. So the problem is that there’s distance between where you’re doing the drawing and the browser. Where the desktop is instantaneous, each round trip to the server could easily be 100ms. That’s just the fact of the internet.

Now, if you have experience with html, css and JavaScript, you could use the WebSDK to fashion your own.[/quote]

Right. Technically speaking you could build the whole drawing tool in javascript and handle locally (local canvas and svg) and only communicate to the server the result of interactions.

It does mean the bulk of your user-interaction needs to be programmed in something other than Xojo, of course. If you already have such a tool (for example, using janvas) you can use as a stepping stone then it would be easier (be aware of license issues).

This way instead of drawing in a Xojo Canvas you’d be really drawing in a local “canvas” and sending the resulting vectors to the Xojo App, which should be able to store them.

Likewise, if you send the vectors back to the web (“opening” the drawing) you should get to the same end state.

As Greg says, WebSDK could be used to build a custom addon for Xojo that does this translation. You can technically use any external tool that can run in a web browser, providing only the “glue” to interact with your back end.

Another option of a drawing program back-end that could be customized for the same needs (they all output SVG, which can be the “format file” exchanged with the back end)is DrawerJS: https://www.drawerjs.com

I have done an application with similar requirement.

The user selects images that can be set and moved in a page.
For each image the user can change size, orientation, skew and many other effects.
Each image is linked to a dynamically created container.
The image is used as css background property of the container so the browser automatically scales the background to the container size: no webimageview and no image scaling done by application.

The effects are applied to the container using css where one of the most powerful is the css transform function used for example to rotate, to scale, to skew and so on.

Drag&drop is used to move containers on the base “page” that is another container used as painting area.
The painting area implemented using a container lets you use drag&drop to identify source/destination items and position and to drop or move other containers on top of the area.
The application using drag and drop events tracks what is moved and where is positioned using the source/destination coordinates of the event itself.
Of course the painting area can have a background image.

Isn’t difficult at all: the application was completed without plugins and javascript code.
it only requires knowledge of css style properties and functions.

Of course the final result can be saved simply keeping track of what images was used and what css properties was used/changed on each of them.
Recreating from scratch what the user has done can be replicated in a flash.

Your explanation fits the same model Greg is talking about. There’re two ways to do this:

  • Handle it all server-side (which is what Bob rightly says would be inefficient for the user). It means all code is on the side of the Xojo back-end. Bob is answering the original question: It can’t be done this way and have it be usable.

  • Handle all local events locally (drawing, resizing, rotating, etc.) and only save the final state. Your proposal is to use CSS (which is valid and original, albeit unusual). A more obvious choice could be to use javascript (which is just as valid and already a requirement for a Xojo application), which may make it easier finding solutions the OP can build on top of.

We’re all saying the same thing. But the “solution” is the opposite of what the original question expected. There’s no single “right” way to do it, but there is for sure a “wrong” way to do it: Doing all server-side.

The problem, where we all agree, is that it requires coding all the interaction in a language other than Xojo, which may or may not be a problem.

I’ve done all in pure Xojo code.
Of course not everything can be done.
Many times things are done as usual and this can’t always fit in a new scenario: desktop canvases are very different from web canvases.
When we speak about graphics we must remember that eyes have a very different perception when compared to programmer’s mind often inclined to “how to do this”