tulamide wrote:what [...] would be the better graphics building?
I don't think there's much to choose between them for graphics per se - high CPU loads are mostly due to the graphics being drawn by Windows GDI+ graphics engine. For example, the shape drawing primitives are doing exactly the same thing as a Ruby call to "view.drawRectangle" etc. - just calling a GDI function with a list of parameters for it to use. The trouble is that GDI uses the main CPU to draw everything without any hardware acceleration from the graphics card.
There's also no frame buffering, so every re-draw begins with a 'blank canvas' - e.g. every time you a draw text label, it is rendered from the fonts even if the text hasn't changed.
To manage GUI CPU load, there are various techniques that can be used - and they all pertain to giving GDI the least amount of work to do. Some examples would be...
- Limiting the number of redraw events.
- Drawing only areas that have changed.
- Limiting the number and complexity of graphical "objects". e.g. a bitmap at its native pixel size is much faster to draw than many layers of vector shapes and text rendered in real-time from fonts.
- Send GDI as many object to draw in one go, then redraw all at once, rather than redrawing it in lots of small sections. Especially true when areas overlap - sections of a background graphic might end up being re-drawn repeatedly when little things that are on top get re-drawn.
From tests that we did when Ruby was first introduced, it seems that primitives and Ruby are about equal so long as you compare schematics that are optimised to the same level, and compare them using the exports so that there are no extra re-draws coming from the FS editing workspace. So I think most folks will get best performance out of whichever system they are most comfortable with - 'green' has an advantage there just because it's been around longer, so the 'best practices' are more established. With Ruby, we're still largely at the "R&D" phase of these kind of optimisations, and many folks are still getting to grips with the language itself - so I think many of the reports of poor performance have more to do with implementations than anything intrinsic to Ruby.
I feel that the FS implementation and guides don't help us much here. Ruby is a very pure Object Oriented language - much more so than C++, for example. But everything in FS encourages us to write code that is much more like a procedural language - it's tricky to use custom Classes of object, for example. So it's easy to fall into what many 'OO' programmers would think of as 'anti-patterns' - for example, creating too many new objects that later have to be destroyed, and not 'encapsulating' data in a way that makes it easy for the garbage collector to manage.
I've been hassling Malc for a while for a few features to make this easier - I don't think that FS benefits from the power of Ruby as much as it could do, because it too difficult to play to its strengths.
kortezzzz wrote:yesterday it crashed a lot
Not seen this here - are we talking 'crashed' as in FS crashing, or the dreaded Ruby 'too much processing' shut down?
. Anyway, we have an excellent starting point here. and we can always put one feature every time. I have some great ideas how to improve the existing concept, and too bad I lack the knowledge to perform it in ruby, but started to dig into the schematic, trying really hard understanding it's logic 