It seems that everybody is experiencing slow down , dead eyes, UI texturing overload with the QC4 UI.
Chris, Steve, can you do something ?
("To make us really smile"....................)
Some ideas :
-hide cables connexions with a keyboard short cuts...
-Hack and provide options to disable all those fancy fat visuals addons in the ui :
-antialiased cables
-reflections on patches
-shadows on patches texts
thxxxxxXx.
(I've had firefox crash twice while typing this reply for some reason -- quite weird)
We're working on it -- our first order of business for KinemeCore 0.5 was to reduce KinemeCore's own overhead (there were cases where it was unnecessarily expensive, and now we're a lot more lean). There are still a few expensive bits that I'm trying to iron out, but overall it's much nicer.
There's also a working (in both QC3 and QC4) line-noodle drawer (I've showed this before, but now that it's actually necessary/useful we're polishing it up). Line noodles draw less than half as much as the curved noodles.
We're also working on modifying patch drawing so it's lighter-weight as well. That's still being experimented with, and I don't have anything to show for it yet :/ Hopefully by the end of next week I'll have an image of that too.
Are those cables really antialiased? Interesting. The black outline makes them look more jagged to me than the QC3 style soft grey outline. I wouldn't have thought those were antialiased in a million years!
Heres's an idea (that I've mentioned in much more explicit depth before); user definable skins, with a "classic QC3" style option. I'm guessing that the art for the QC3 style patches isn't anywhere in SL though, so that kind of sucks.
I'm kind of fascinated with the idea of hiding cables sometimes, but I think it would confuse me :) No doubt it might be a cool option. Whatever happened to the "straight" noodle thing, cwright? Not that easy on the eye? When all is said and done, I guess it could get kind of convoluted since the Interaction type uses the straight noodles. I still find it to be a cool idea.
Oh cool, that's what I meant by "straight noodles" in the message below. Great, they're yellow ( I don't know why they wouldn't be, but they don't look like Interaction noodles in any way, so that's a big plus).
As far as k-core stuff goes, what about an "unpublish all" option? Obviously, while one is working on something one just hits "undo" and everything unpublishes, but when one has a qtz that is already done with a ton of published parameters, it's really slow to have to unpublish every parameter so that all of the values store.
Why is it that QC is so lame about that? Doesn't it make sense that if one was to cut a macro with published values, or copy and paste, that all of the values should remain instead of zero-ing out like they do? What a pain that is. Another thing I notice that is always really irritating is how undo doesn't seem to "undo" changes that have been made to published values (I have not regressed that on a clean system, but I do note it in both Leopard and Snow Leopard).
Unpublish all: done ;) (did that a day or two ago)
[cough: that exposes a lot of other new-ish stuff too; Extra Editor is done, transmutate macro is not (yet), inspect is not (yet)]
There aren't enough QC users to sustain a "theme" community. At best, we could do a cheap-hack 9-piece bitmap for patches (plus a bunch of other details), or write our own.
There's no "art" in QC, just Quartz Drawing code. The drawing code in QC3 is rather easy to extract (to a trained reverse engineer), so reimplementing the qc3 style in qc4 is only a few days work (maybe a full week or two if wonky changes took place -- quite possible).
Another problem that's in Leopard (and possibly snow leopard) is that when you scroll the editor, instead of reusing the chunk it's already drawn (the vast majority of the window, most of the time), it redraws the whole thing every time. It's kinda lame (if you enable reuse on the NSScrollView, it ends up creating glitches because they hack patch positions to make the editor's size appear to be infinite, so reuse regions don't line up at all). If this is still the case in SL, it's also something that should be fixed (but fixing that's a lot of work, as all the "virtually infinite editor" position hacking code needs to get changed).
The editor also isn't at all threaded -- threading the viewer is a ton of work, but would make things very nice. Threading stuff that can be threaded (nothing comes to mind, but I've not thought about smaller places to use threads) could also help responsiveness some.
The following are graph eval performance issues, not editor issues.
Every GL state port (Blending, Culling, Depth Buffer) calls a method (-[self indexValue]) (12-24+ns) to access an ivar (_index) (2-3ns) twice per execute -- this isn't a big deal, but it's stupid design. GLTools "fixes" this for Blending ports.
Every port sends a notification (which takes a spinlock) every time its value changes -- this is for inspectors to update them. However, 99.9% of the time this isn't necessary, as no inspector is listening. This should be fixed.
QC4 also spends a significant amount of time creating arrays of patches to execute to speed up graph evaluation. Unfortunately, the apple engineers apparently didn't actually measure the performance, because it's either exactly the same as QC3 (without all the work), or it's half as fast (twice as much overhead). There aren't any instances that I've seen where this "optimization" is significantly faster (Except for when all a macro's subpatches are disabled -- then it can skip rendering an entire frame, which is cool, but unlikely to happen in normal usage).
I can't tell you how many times I just bust out the plist editor and change the macro type. It's so much less irritating than rewiring stuff (in very specific scenarios, of course... it's not always ultra straightforward). If I have a bunch of stuff in a macro published to root, and then I'm going "hmm, I want this to be in a lighting patch, 3D transform, FOV, etc", it always seems way quicker to just edit the plist if the qtz is already really locked in and I have to rewire a ton of stuff. I'm really excited about the idea of the macro shifter while actually in the QC editor environment.
What was extra editor? That's not the extra Viewer pop up idea, is it? Timeline/sequence hack stuff? Looks like things are shaping up awesomely! If that's a screengrab of SL, I'm really happy (ok, I know that's not SL, but still). Boy do I ever retract my statement about reservations of flying the QC3 look into QC4 though. It doesn't seem like nearly as much of a luddite idea a few months down the line (not that it is necessarily feasible to put something like that out there... not sure).
In short, Extra Editor is awesome. You can open editors for macros (or for the root macro patch, if you want), and edit in multiple places at once. smokris and I ran into many cases in our huge VJ performance where we'd be working in two different locations 3 or 4 levels apart, and constantly switching levels (especially when publishing ports) was error prone and tedious.
It's a bit weird when you delete the containing macro -- not sure if I'll have a good solution to that before 0.5 release (it doesn't crash, it just makes a "virtual root macro" in the editor that doesn't match up with anywhere in the actual composition)
[there's no limit to the number of extra editors opened for a qtz]
Oh, I know that there aren't enough QC users right now to warrant theme stuff right now, but I still think it would make the app more impressive to people and seem like it has the same flair in the small points that makes OS X "cool".
Would threading the Editor help the little lags that happen in the Viewer while scrolling around the Editor, or would the Viewer have to be threaded as well?
I almost don't even want to think about the some of the ridiculous "optimizations" that have happened. It's just disheartening to have had so many things that weren't broken "fixed", and in that pursuit, actually breaking them. What you say about the Inspector scenario is pretty lame. I find it interesting what you are saying about QC4 making patch arrays... that seems kind of weird, because I don't see how that could_ever_result in better performance. When does anyone ever setup a qtz disable all of the subpatches in a macro, as opposed to shutting off the macro? Hmm. (raising eyebrows)
The "non-curved " line noodles drawer is a really good thing, it should really help to speed up the editor.
Have you seen how patches are displayed in debug mode ? In QC4 when they execute, they show flats colors without reflections on top of themselves...
Perhaps a way to go. Customs colors for patches should be a good option also. I'am not very fan of lot of colors in UIs but I have to say that the actual one has two much contrast with those blacks patches....Pure white text is also a sacrilege. The dark theme was a good idea but it is actually very triste, i loved the subtil pastel look of QC3. I don't know how may layers they have to draw to display a patch but even the selection color has a yellow to orange gradient... What is really hurting eyes is the white reflection in the top of the patch.
I do a little test to see how it could look with a dark blackboard style but with soft color :
an array of patches (in memory) can be used for fast enumeration to execute patches (in QC3, the only way to discover the order was to traverse the graph every single time). However, it doesn't ever seem to reuse the results, so as far as I can tell IT'S STILL TRAVERSING THE GRAPH every frame to find the order, then building an array, then executing them (which ... is more work than not building the array and just executing them in place).
If it was hardcore, and noticed that a consumer (and its producers) would always execute (and keep that info across frames, and never traversed that portion of the graph ever again), array-dispatched patch execution would be quite fast (in most cases, there will always be some patch that always needs to execute, and not needing to traverse up to that point can save some time). That's a ton of logic though, and a lot of work, and, quite honestly, C-based structures would be traversed more quickly with less overhead without the need for array creation/copying/destruction (this is what hobbles iterators in QC4 under many circumstances)
I laugh :) That's really awesome, but I'm still so stuck on the idea of multiple Viewers/"sticky tooltips" for constructing scenes and placing objects on one another. I've already come up with my workarounds, but it's a performance hit for sure (duplicate GL scaled macros, in separate 3d transforms).
I guess that the classic quick workaround would be to put stuff into a trackball, but that's lame if you want to be publishing stuff to root as you go along and at the end of it all, you don't want a trackball in there.
Weird about the non existent virtual macro thing. I guess there is no way to have the window "just close"? So what happens if you delete the containing macro, the editor is still open, and then you put more patches on the surface? I guess it would be possible, but then it would still be virtual, so it would just be "hanging out", but not active?
FYI, one of the macro environments in the iDVD plugin renders a border, but it's also an environment patch, so it's a little unique; everything in it just sits in there and doesn't evaluate. Then, in SL, if you explode it, everything turns live (at least it did a build or two ago). I thought that was cool, because it's like one step away from having a sprite be an environment patch or something like that. Really quirky.
I don't want you to think I don't remember you explaining that to me before. I definitely do, and was referring to the point you just made about the graph being transversed every frame anyway, so the whole setup seems rather ill-conceived.
Random thought; I wonder if the new route ever helps in the efficiency of the DAE/Mesh rendering stuff. I'm guessing you've probably looked at that already.
I know I've explained it, but I think that was exclusively via email -- I figured putting that info in a slightly more public place would be beneficial in general.
the traversal stuff might be useful for mesh rendering (though I don't know how, meshes are the same as images or structures or numbers, as far as the graph is concerned), but since that's not available on QC3 it's impossible to profile... :/
it's possible to have a window "just close", the trick is getting it to just close when the containing macro is deleted (we currently don't hook any patch delete methods, so we can't tell when it's removed -> can't close the window). Not saying it's not possible, it's just finding new places to hook things that I might not be motivated to uncover at this point.
If you add patches, they get added just as normal -- but internally it's now an independent composition (of sorts -- can't be saved etc.) So "hanging out" is 100% accurate.
the "inspect" menu is intended to address sticky tooltips + associated requests. Not quite multi-viewer (which would adversely harm performance due to redundant graph traversals), but hopefully something close.
It's pretty easy to make patches that allow subpatches, but don't actually call them -- the default configuration for a patch is to allow subpatches, so you actually have to explicitly program them to not allow subpatches. If you implement anything in -execute:time:arguments, subpatches won't get evaluated unless you call the proper method (executeSubpatches: or something like that). kinda quirky, but it makes Macro Patches simple (every patch in QC is a subclass of QCPatch, which is actually the Macro Patch ;)
Cool, I just didn't want you to think that your time explaining that was wasted on me :) I'm thinking "man, I hope Chris doesn't think I'm that dense" :) !!!
It's totally wrong to go on gut, but I have a weird feeling that some of the "poor" changes were made to mitigate possible problems with using OpenCL/DAE/Mesh Render in certain scenarios.
For instance, I flash on how, when one had a file that is a really resource heavy and you cut and paste, how QC just sits there and beachballs while the resource reloads. Now, when you cut something in QC, the thing stays in the Viewer (lame), but now by the same token, when you paste it, it doesn't have that reload stall, at least of the magnitude I would expect. I don't stand by that comment because it's kind of comparing apples and oranges, and too much other stuff is different to do a real a/b (for me at least). It might not have anything to do with changes in graph evaluation at all, but it wouldn't surprise me if it comes into use to help coddle the dae stuff into reasonable performance. Again, total gut instinct, not scientific, and by all means I shouldn't be posting that kind of drivel :)