Memory Leak

[WolfieWerewolf]

Hey bro... I accidentally left the online makepad demo running overnight and when I checked the Task Manager in chrome (I'm testing on a Parallels Windows 10 VM, this morning, ) I noticed that the memory had grown substantially..

In case you hadn't noticed this I thought I would report it.

While I'm here I have a question... Your turtle graphics implementation.. did you write that from scratch or port it in from somewhere? If it's borrowed do you mind sharing the original source location? Thanks.

/W

[makepaddev]

Hey thanks for reporting, i'm rewriting everything to such an extent though i'll have to look at it again once thats done. The turtle graphics is something i wrote from scratch, ideas of course originating in the 'logo turtle'. I was thinking of ways to reduce API 'width' aka what you need to do get something, and the only real answer is 'state' also known as turtle. So i decided to figure out an entire layout and graphics api on top of it. Feel free to take any code or ideas ( i can advise just doing the ideas since the code is probably going to be hairy.)

[WolfieWerewolf]

I hear that man... I'm constantly monitoring CPU / GPU / Memory for my WebGL work that it's become a bit of an obsession... I appreciate that you are re-factoring... I've found that sharing GL resources like textures and clearing them instead of creating / destroying them is a big help.. Same with shaders, if you're layering, even in an ortho scene, and the uniforms don't change between use cases you can easily get away with re-cycling shader programs cutting back overhead related to calling into the GPU.

I'm familiar with the logo programming language which is why I find your turtle graphics implementation so interesting... Thank you for offering for me to use it.. I may take you up on it. I think we discussed this before but despite my years of working in JS I find JavaScript very difficult to read.. I think it's the "free-flow" nature of it. Maybe it's my background but I find typed languages so much easier to follow... I'd really like to pull out your turtle code and play with it in my environment but I think it would be a lot of work just to identify the dependency hierarchy. This isn't a criticism of you or JS.. It's actually a criticism of myself for not being better at reading JS.

I haven't gone through your code enough to know this but are you generating vectors from the turtle calls or textures?

Thanks

/W

[WolfieWerewolf]

I answered my own question.. going through your generated shaders now.. wow, nice work man.

[makepaddev]

Yea i'm pretty sure i just messed up not freeing some resource, i have had a long period of 'not checking if im leaking' The design isn't stupid about leaking, but i'm sure i made a bug. Also yes the reason i write JS alone is because i can almost not work with other people on large projects. I can't read their code, and i can't reason with their decisions or architecture which causes me to get stuck in a complete inability to refactor anything very quickly (or fix bugs). Whereas if i write things alone (or in tight pair-dev.. that does work) i learn about everything and i can fix bugs almost instantly, and i gather extremely useful information on what to do in my next refactor.
Also because JS is weakly typed it really is a case of having a good memory to be able to even do it at all, even alone. The reason i do like it though is because i'm extremely fast in it, much much faster than i ever was in C++. I can undertake enormous (from a C++ point of view) projects and get somewhere, alone.
My opensource strategy is also 'please take it its free, but i'm not supporting it' Reason is because i'm not done solving the hard bits yet, and i dont wanna be slowed down. Also because i want to be free to break anything i want to improve the design, without having to weigh that decision based on the number of pissed off users, contributors or otherwise.
Someday, of course i will support makepad otherwise why attempt it. But only when i feel like its ready. On the use of code: be ware. The turtle thing is more of an interesting reusable concept than a very useful implementation for random other uses right now.
I've evolved it (rewrite from scratch) about 10 times, so its definitely useful to understand how it works since it contains a fair amount of evolutionary solutionspace.
But once you do i can really advise you to write your own because only then will you really understand what it does, and then you can also improve it. Even tell me about how you did it, so i can learn from your exploring as well.
So, bit of explaining then.
The turtle is a 'tree' of little state objects which i call turtles.
A turtle 'walks'. So if you output a rect, generally it will walk to the right the width of that rect.
This means that 'as you are drawing things', and unlike canvas, there is this thing int he back that knows the current x/y. Also it can test if the rect you are drawing would be larger than the width, and line wrap. Ok so now do this concept recursively.
So that 'rect' you draw can actually be a full box of other stuff you draw, with its own turtle. This is called 'turtle nesting', the question is how on earth do you move all this stuff to linewrap, since the draw operations 'in' that rect also just output a bit of vertexdata. That is where the magic of the layout system comes in which is 'lookbehind only'. That is i can only move things ive drawn, but i cant resize it. Since the codeflow to do the wrapping is 'inline' it can never be reexecuted magically, but i can peek behind and just 'move' the x/y values that i wrote into my vertexbuffers.
So thats the essence of it. Hope it makes sense, but i see some road ahead where i will have to explain this to people in much more detail :)

[makepaddev]

The hard bits are to fully complete a layout engine within this constraint of never resizing 'after' you called the draw method on something. For instance imagine A --B-- C where B fills the space between A and C. Problem is, if you draw A B C in that order B cannot be sized correctly because it hasnt' seen you want to draw C yet, so it has no understanding of its size. So in order to do A--B--C you have to draw it like, align-right C, align left A, fill B. So thats the constraint. Sofar i'm quite happy with it

[WolfieWerewolf]

Interesting... That does help actually.. I wish I had the time to take it apart and do exactly what you said, "re-implement it and share the results" because I think together, outside of either of our environments, as a discrete UT we could probably come up with something pretty awesome around this concept alone.. I don't know about you but I have very little time for this kind of thing.. unfortunately. I will be thinking about it though and if I do take the time to explore you can be sure I will share my findings with you... great work though, it's an impressive project especially given that you've written it by hand in JS...

[makepaddev]

And yes there is a class of UI you can't do with it. My solution is 'just hardcode the layout' or just don't do it. Life is too short to either understand or build the ultimate layout engine imho.

[WolfieWerewolf]

amen to that!

[makepaddev]

And no i don't really have time nor need to isolate this bit into a library, nothing in makepad for that matter is a library thats reusable as i prefer the system fully integrated with a single goal: make an awesome online live coding environment with unified (as far as that concept goes) CPU/GPU codespace

[WolfieWerewolf]

Yeah I get that.. I was strictly speaking from a UT perspective.... no as a re-usable implementation... I find the best way for me to understand stuff is to break it down into tiny little pieces but I get what you are saying.. Makepad is like Blender... the UI Kit is the app, not a framework...

[makepaddev]

Sorry UT? Acronymn not expanding

[WolfieWerewolf]

Unit Test... Discrete implementation that does just one thing to prove it's functionality

[makepaddev]

Yea in that regard the layout engine is woefully undertested as well. In this last rewrite i will probably make more tests as i'm now fairly certain how this should work. Don't forget i have rewritten this from scratch probably 10 times now, i haven't yet had much use for tests except to keep throwing them away every time.

[makepaddev]

Makepad is its own (fairly large) integration test in that sense, and i do write little test html files to decomplect some things to the point i can fix bugs.

[makepaddev]

But even if i would have made extensive platform tests last cycle, i would have thrown them all away now since its getting a whole new concept of how to do out of thread APIs. I'm making the frontend of the compiler running in the user-worker with the process, outputting a serialized binary AST that gets sent to the main thread where it can either compile it into safe GC-free JS (or wasm) to talk directly to the webGL/audio apis, or into GLSL. Teeny tiny bit like a hobby LLVM architecture.