JavaScript API about geometrize-haxe-web HOT 14 CLOSED

It should be possible to enable by adding @:expose metadata (https://haxe.org/manual/target-javascript-expose.html) to the library code (this repo: https://github.com/Tw1ddle/geometrize-haxe), I expect you'd only need to expose some of this:

https://github.com/Tw1ddle/geometrize-haxe/blob/master/geometrize/shape/ShapeType.hx
https://github.com/Tw1ddle/geometrize-haxe/blob/master/geometrize/runner/ImageRunner.hx
https://github.com/Tw1ddle/geometrize-haxe/blob/master/geometrize/runner/ImageRunnerOptions.hx
https://github.com/Tw1ddle/geometrize-haxe/blob/master/geometrize/exporter/ShapeJsonExporter.hx
https://github.com/Tw1ddle/geometrize-haxe/blob/master/geometrize/exporter/SvgExporter.hx

If you're not used to Haxe then I'll have a shot myself at somepoint, also happy to accept a PR. Thanks!

from geometrize-haxe-web.

yes, just the basic public API. thanks! let me try first and if I'm blocked come back to you . The thing is that there are a couple of JavaScript ports but seems to had taken their own life, supporting or not arbitrary features, and none oriented to APIs but more to demos so I would like to give it a try and generate JS API directly from geometrize-haxe which I think is "official".

Quick question: What's the relationship between the C++, go and haxe implementations ? are the three independent from each other ? if so, is there a common minimal official API . are their functionalities too different from each other? I'm concerned about this and not so in the aesthetically result (which is amazing) because i see as a library it can have other uses, for example bitmap to vector converter. I think this is an aspect the library could exploit. Wonder what do you think?

Thanks again!

from geometrize-haxe-web.

Primitive was the original implementation for this technique written in Go (https://github.com/fogleman/primitive). The Geometrize Haxe and C++ libraries are my ports of Primitive, but each some missing features and have modifications. The hillclimbing optimization algorithm at the core of it is the same though.

Someone asked about bitmap to vector conversion the other day: Tw1ddle/geometrize-haxe#14 - discussion there might help. It depends on what you're wanting to achieve with that 😄

from geometrize-haxe-web.

@Tw1ddle in order to use the library as a bitmap-to-vector converter, what would be the best runner options for generate a replica of the input image ? I guess it will be shapeType=ALL but not sure about the other options.

This is an excellent result with the following options but it takes too long:

Elapsed time: 92.998 seconds.
Output size: 709.89 KB.
Options: {"iterations":10000,"shapeTypes":[0,1,2,3,4,5,6],"candidateShapesPerStep":50,"shapeMutationsPerStep":100,"alpha":128}

Thanks!

from geometrize-haxe-web.

The more shapes-per-step and mutations-per-shape the better the results should be, but more time would be needed after increasing those.

You could also try leaving out rectangles, circles, lines, and use rotated ellipses and/or rotated rectangles on their own.

To improve performance I think you'd want to do a drastic rewrite and run the rendering code in a shader or similar.

from geometrize-haxe-web.

aja! thanks for the tips. I will start writing some tests using different settings and image sizes. Then compare times and image diffs for each. Hopefully this gives a clear understanding.

In the meanwhile this is the project / repo:

• package: https://www.npmjs.com/package/geometrizejs - (geometrize-js and geometrize names were already taken in npm)
• repo: https://github.com/cancerberoSgx/geometrizejs - zero implementation - although still needs tests, the happy paths are already covered. Using git submodule as you suggested.
• Playground: https://cancerberosgx.github.io/demos/geometrizejs-playground/ : no workers / performance considerations at all, only svg, needs cleanup and UI design but basic use case is working.

I will keep working on this, when I think it's ready will comment here so you can link the project if you think is worthwhile.

About the API and not important but want to track it somewhere a comment: in the typings, Rgba (referenced in Bitmap), Shape (referenced in ShapeResult) and Bytes types have names but no signatures (TypeScript any type). I will review this in the future - here some thoughts:

• I can probably remove references to Bytes or leave it as it is right now
• Shape could be represented (on my side) with a readonly interface (don't declare members that set/modify since users don't need to)
• But in the case of Rgba, seems it could be useful for users to create colors, and in that case maybe is better to expose it (?)

I really would like your opinion here since I didn't design/implement anything I don't think is my place to take these decisions so please comment if you disagree with anything.

The only thing I did decide was to flatten the package/module structure: i.e. instead of new geometrize.runner.ImageRunner() or new runner.ImageRunner() users are able to just write new ImageRunner(). This is because, in JavaScript is not possible to import members/types nested more than 1 level and, in my experience, JavaScript developers hate to work with absolute names or declare shortcuts alias. Also IMO, this exposed API is that big for needing namespaces, yet. But again please comment if you don't agree since you did designed it - I don't have problems to make radically changes to the API at all if you decide so. Nothing in the lib is final - I published so we can discuss :)

Also, tell me if you want me to give you write access to the repo, would be my pleasure.

Final note (I promise), I plan to keep writing tests and use CI like travis. Would be awesome, in the future, to automatically generate the entire library from your's. That way js tests can execute when pushing haxe. (kind of integration tests for geometrize-haxe). That has a cost on my side though so right now I don't think is a priority.

Sorry for the large comment, won't bother you any more. Thanks for all the help and tips!!

from geometrize-haxe-web.

That all sounds good!

• I could add a define (https://haxe.org/manual/lf-condition-compilation.html) so you can build without referencing Byte, or maybe just remove it from your code for now.
• Shape would indeed make sense as a readonly interface on your side.
• Rgba is an abstract that (I think) disappears when it's compiled. Adding helper functions to create colors could be useful but you can could use an integer like 0xRRGGBBAA.
• "geometrize" in the package name works for the Haxe library imo, but I agree dropping it in the js makes sense.

I don't have much time to contribute at the moment but might be able to in future, so write access would be nice.

from geometrize-haxe-web.

You should receive an invite for my repository.

I almost added some extra features on it but but I won't - it won't have any implementation, just typings for haxe. I probably create a geometrizejs-extra repo with some ideas - APIs I need. Listing a couple although I'm 99% sure they currently are not supported perhaps with more time in the future something similar could be added to haxe (the next is thinking about haxe - probably in my js-extra implementation I will not follow these rules:

1. a high level Runner API that also implements the steps iterations. I omitting the image Bitmap leaving it for the end.

2. an async event listener API called on each (or between N configurable steps?) that waits for a user callback so they can control timing and rendering as they want.

3. User is able to change options, including the new one iterations (and why not the image source too?) passing them in the callback I think that would add really value- not only I'm able to batches of images, but also using transparency and options parameters may be perform something creating ?

4. this is what I need for big images, in the browser since it's kind of slow. User is able to serialize results as string and later, in another process instance, load them. So I can make sure I won't loose a long image processing or I can continue with it int the future. For live animations this could not be important but if experimenting in node or browser without animations just to see the final result in a large image (like me) this seems to be a killer feature

And finally something I'm not sure how to solve it:

• as user I don't want to learn how to parse a JPG/PNG and build the Bitap to load images, This would be perfect: the URL just be enough and let's an jsweb or node.js haxe or haxe-web adapter take care of the rest:

var runner = new ImageRunner(new JavaScriptWebBitmap('http://foo/cool.gif'))
or new ImageRunner(new JavaScriptWebBitmap(document.getElementById('img1'))
or new ImageRunner(new JavaScriptNodeBitmap(readFileSync('tiff')))

( Nevertheless should be blackguards compatible so still allow me to do it by hand)

To support this two, I don't see other alternative that each "environment" implementation (haxe, haxe-web, node.js , js-desktop) provides both with the contract and the implementation of this adapter and that should be outside core libraries.

Or that sounds painful now I'm reading and I'm getting too purist? The last part is not really important for me but just remove the image parse and loading from user's responsibility since I think it can be a stopper for them.

Well, seems that again my comment is sooo large, sorry. Thanks!

from geometrize-haxe-web.

Rgba is an abstract that (I think) disappears when it's compiled. Adding helper functions to create colors could be useful but you can could use an integer like 0xRRGGBBAA.

I think the problem is not Rgba but Bitmap which has public methods like setPixel and fill() which requires users to access as values and if I understand correctly they are the only API to write the bitmap before the step and so have an impact in the evolution of the iteration itself right ? Users can always write after a step but since bitmaps are cloned wont hae effect. AM I right ?

Regarding the color format, if the colors and the byte array are not doing/using something special, then the bitmap data object, as in https://html.spec.whatwg.org/#imagedata, it's our compatibility common point. I see that Bitmap represent this but it a has also instance methods that pollute the "standard" so probably I will create a PR in haxe to encapsulate the "RawBitmap" an data-only interface and make the instance methods delegate to a rawBitmap property, if that's fine for you. This will allow me to freely substitute an object created byUser code with one crated ny haxe code which is currently not possible.

I think I just discovered an important performance issue on mu side (my bitmap is cloned unnecessarily twice) - probably I will need to modify Bitmap also for this one. Basically I want to avoid first two bitmap copies before first step since for bit images the delay is noticeable.

• I could add a define (https://haxe.org/manual/lf-condition-compilation.html) so you can build without referencing Byte, or maybe just remove it from your code for now.

If I verify the commented issue, I think I can remove Bytes, I think the guest language code is responsible of building its own Bitmap instance, with the tools / parsers / resource types APS. I think is only meant for haxe code.Perhaps i the If the list of target languages groups you could consider identifying and hiding these internal members behind interfaces, perhaps when I publish geometry-flash :P

Don0t worry jsut for me, I just wanted to mention things that didn't close up on my typings as a feedback - I'm really happy with I have now, still missing things like documentation and the CLI, but it's getting hard to focus since I can't stop taking pictures now:)

Thanks

from geometrize-haxe-web.

Thanks. I've also offered you write access to the lib, feel free to make changes, though please keep it compatible with my web demo. Your suggestions all sound good.

Yes the Bitmap objects get cloned, that stuff could be cleaned up. An interface would work, or if I recall correctly, @:expose should also work on individual methods, so it might be possible to just not mark those methods.

Higher level API in an extras repo makes sense. When I have time I can look into adding some more functionality to the Haxe library, perhaps extracting/refactoring code (like loading images) from my web demo and putting it in the library.

from geometrize-haxe-web.

FYI I added you as a contributor: Tw1ddle/geometrize-haxe@1d67d7b#diff-9879d6db96fd29134fc802214163b95a

And noted your project in the readme: https://github.com/Tw1ddle/geometrize-haxe#javascript-usage

Let me know if that's fine, and thanks!

from geometrize-haxe-web.

Thanks! Asking your preferences before breaking :)

It's OK if I create an issue to track some details I want to review / test and perhaps fix regarding performance ? Or do you prefer I create a pull request 0' If I were to change something, do you prefer I create a branch here or should I keep workin in my fork ?

it will be on this library code alone but O'm writing the tests I 'm writing on mine since I didn't familiarize with any haxe testing framework. Since are only typings I don't think it's so bad for have an initial idea. and it's not a benchmark to publish is just to make sure if I change something it really speed up things...

And noted your project in the readme: https://github.com/Tw1ddle/geometrize-haxe#javascript-usage

Thanks! will finish the CLI ASAP then since currently it does nothing

Thanks :)

from geometrize-haxe-web.

Branches sound fine to me, feel free to approach that however you like.

Fine to keep your unit tests separate. Just so you know I made a Haxe unit test repo long ago, though it is mainly stubs: https://github.com/Tw1ddle/geometrize-haxe-unit-tests

from geometrize-haxe-web.

Aja I was just going to ask you about that could I use that at least just to give it a try? at least just to push it so if it still green in travis. Although the performance I writing righ now are not specs , just normal programs that log some timings , this seems the oppotuninty to get started with haxe I was saving my self for something more low level but another one won't hurt ¡, thanks!! (seems you have good coverage wondering if nyc works for coverage there 5.. thanks!

from geometrize-haxe-web.