Developing Graphical User Interfaces with JUCE, part 2

okay part two and now I talked about how you get your components on the screen in this half I want to dig down into actually how those things get drawn and talk about the graphics context and dig into what's actually going on behind the scenes to get those pixels onto the screen or into an image I'm going to start by having a look at the main class that you'll be using when drawing which is the graphics context if I can find it in here graphics let's just have a look at the class it's a non virtual class the there are no virtual methods in there the graphics class itself is basically a wrapper around other simpler rendering functionality so it has a whole bunch of methods draw tech we're starting like setting fill types gradients the opacity you're going to be drawing with seeing the color you're gonna draw saying funky ones rule with and then you can all these methods to draw some text to fill rectangles to draw rectangle outlines to do rounded ones checker boards all kinds of things that lips is here lines dashed lines horizontal vertical lines stroking paths arrows for join images so basically a whole bunch of handy functions all the way to pretty straightforward and honest rocket science what happens inside this class is that all of these calls some of them go directly through to lower layers that actually do accel pushing operations others are kind of high level composite operations that may cause some other stuff internally and then pass through to two lower level operations you get a graphics class a graphic graphic object to work with you generally don't ever create them you'll get given one when your paint methods called and you can create one if you want to draw it into an image so you'll create an image and then you will create graphics object give it the image as parameter and that'll let you draw into the image but that's really the only two times that you're that you don't see ways you get one of these I think most of you will have used one of these many times so I'm not going to go into details about how they actually has actually draw things I was already using one earlier for the for the demos but I will go into a bit of internal background and what's actually going on when you call this thing and say fill a rectangle or turret or an image so here we are in the juice graphics module in the context section we have this graphics context file is the graphics context that we all know and love but the ones the other files in here are ones that you probably never looked at what this one here is a base class and this is a low-level graphics context you're never going to need to create one of these but I will show you what's going on because it's quite important in understanding what's going on behind the scenes the graphics object that you're painting with has one of these inside it and this is a virtual base class and this is a basically a cut-down graphics object it does a few things basic drawing of rectangular images clipping and this virtual base class there's a I think three or more maybe four subclasses of this which you actually use if you're on that if you're running on iOS and on iOS or OS 10 then you're going to get a version of this which actually does all of these methods of fire core graphics and these calls will go straight through to a core graphics call that might draw a rectangle or draw an image and then we let the operating system worry about how that works if you're on Windows where historically and certainly when I started doing all this stuff there was no actual decent rendering engine that could do anti aliased paths or sponsor and thing then I wrote my own so we have a software the low-level graphics software renderer which is a bit of a mouthful but that's this is an instance of that which actually draws it using the CPU into an image so this is this will work on any platform and what you're going to get from all of these is a pixel by pixel the same result so if you use a core graphics context or one of these software renders or an OpenGL renderer or whatever other crazy ones we cannot out within future the idea is that what you actually end up with will look exactly the same on the screen so the software renderer that is strictly true at the moment yes okay it's not strictly true at the moment it's mostly true that the fonts are there is a slight difference in fonts because on OS 10 core graphics has some sort of funky font renderer which fattens the glyphs slightly using a cunning algorithm that can't quite work out the the my software renderer will will be pixel for pixel same as that the OpenGL renderer I think claim because they both use the same font rendering engine but it's slightly different to mac on a high enough resolution display you would never know the difference but yeah if you're if you're still using an old VGA monitor and sitting very close to it then you you may you may get all that that that I think that's character those a little blurry or whatever but yeah certainly if you're doing paths or well paths are actually 90% of all what you do all but paths images and fonts are the three really the only three things going on paths will be the same images will be the same yeah funds known only the software renderer I will just quickly show you what's going on behind the scenes in that one there is a not that one you can you can dig into this stuff at your leisure but there's a big file here called rendering helpers so if you if you're interested in digging around in the back in in the in the basement of juice and seeing what's in there this one's a good one to look at rendering helpers this is a big ol file this is basically a 2d rendering engine that's been templated out and this is code that's used common in common between this software renderer and the OpenGL renderer so this stuff does it'll take a path and it'll flatten it and it'll then draw like horizontal X or Y wide lines to render paths and it'll do all the anti-aliasing at the edges there's stuff in here to handle fonts and caching the glyphs of those fonts and yeah if you're ever bored on a long winter evening and you want to dig through some code there's a lot in here too to keep you entertained and this is you yeah this is you've been certainly by currently the two the two main renderers for windows which are GL and and software renderer the core graphics one is much simpler because most of the calls are just straight through to 2/10 now the the way these contacts work is they're very stateful so generally at any moment a graphics context will have a state which consists of a clipping rectangle a color possibly a fill type because you might set the fill to be like an image fill or a gradient fill and a transform and as you push and pop as you as you make changes to the graphics context you'll often want to say okay so save the state at this point and now I'm going to change the color change the transform I'm going to draw some stuff and now I want to go back to the original state I was in before and this is generally how components get rendered a parent component will be painting itself and it's time to then it's time to paint its children so it'll say save the state save the clipping rectangle save color save position and then it'll let the child do whatever it wants mess up that context it'll pop the steak back to where it was before and to do that we have a function in graphics which I've lost we can save state and restore state and we also because we all love our AI I don't we and that's not optional we have a scope to save state so you can't forget to restore the state so if if you're drawing some so let me show an example this if I go back to my my earlier main component and look at the code here's the bit where I actually that's get rid of the my skipper the other things in there in here so we can see the painting so there's our hello world let's say I want to draw half of my hello world in red and half of my hello world in green but I don't want to do it by actually just drawing font so I want to actually clip it down the middle of a letter or something so what I could do here is for my graphics I can save the state and then I can clip it I can reduce look great so I come over there so first of all let me see if this if this works just a second so there we go we've got hello whoop because i've what i've done here is i've added a clip region so before i draw the text i i'm clipping only half the this this graphics consists now only joins the left half of the component so my hollywood gal gets truncated but before i did that i hit save state which made made sure that everything the entire state of that graphics context is now pushed onto a stack and then when I call restore state here it gets put back so so after this I can then copy and paste this code which you should never do and I will say I need to remove from right and now I'm going to change the color and do the right half of this in red and then we've got hello world with half green and half red because when I restored the state it meant that I was back to my unclips version I could draw anywhere and I can clip it down again on the right so this is kind of the same thing that's going on behind the scenes all the time when you have components and when because when you're drawing it a component like we saw before with the painting is unclipped stuff before your paint method gets called the the code behind the scenes will have made sure that it's been clipped into the right region but after it's let your your your component paint itself it needs to go back and let the other bits paint so this is how you do it and stuff like this actually maps on pretty-pretty one-to-one mapping on rendering engines like like core graphics where these calls we pretty much going straight through but in all cases it's kind of expensive to save and restore the state so in general it's not something you want a lot but that's how that works we also have some transparency layer stuff so this is this is kind of advanced graphics what you can do it's bit complex an example of this but if you're about to do a bunch of rendering so this graphics context where you then want to do some there's something then you want to change the opacity of the whole thing you can begin a transparency liar do your drawing and then call any transparency layer and then whatever a pasty you gave it when you started is what we'll be applying to that whole thing now it's not that's a very different I'll show an example to show how this is very different from simply drawing with with a lower transparency so if you go back to our example I'm just going to get rid of all this hello world stuff I'm going to draw two rectangles so I'm a fill correct 10 10 100 hundred and I'm going to do that in not in green but in green with an alpha so I'm going to do this half half a cake and I'm going to then draw another one in half a cake loop and I'm gonna make these overlap slightly so I'm gonna make this one that say 60 come at 60 so there are two semi-transparent rectangles being drawn imagine we did the same thing now with the the transparency layer stuff so I'm just going to copy and paste these because easier instead of drawing to naught point five alpha rectangles that overlap each other way we get the overlapping bit let me draw two solid color rectangles but draw them both into an alpha layer so I say G begin transparency there and let's make the whole thing your point five and then I'm going to take away these alphas on these neurons so these are now solid but the whole thing is transparent and then it's that's actually correct I'll turn it I'll turn the Alpha down on here so we can actually see I see it more clearly but that the overlap is gone because the two things are solid but the overall the the whole after after the two things have been rendered solid that the overall thing is now rendered down within the 0.5 transparency now this mechanism behind the scenes is how you can turn down the Alpha on the whole component because when when you have components and you want the whole thing to fade in and out to animate things coming going you can't just draw everything in it with an alpha with a different alpha because you're going to get strange overlapping blurring color colors between the items in its so you have to have some mechanism like this and then this behind the scenes is what would happen if I set the Alpha of my component which I can also show if I go back to my it's a and a blob back so there's my blob I'll just get rid of this this stuff here so now I have my red blob but say I want to fade that red blob out components actually do have a set alpha so I can as well as I think of transform now I could take my blob and said alpha of its you know point - and we should see a faded red block and behind the scenes went before the paint method on here gets called then some code will call begin transparency layer it'll let this thing render itself called n transparency layer and that's how that gets done and that would be a very different result if the blob just rendered a red not point to alpha red blob and I'm not going to offer blue blob yes I should say if you're if you can ask a question where you would Kris over there and he'll bring you in my phone she's Kris and so what actually happens and there's off the renderer during this does it render the rectangle to memory and then copy it all across multiplying a little bit of stuff and adding something happens it could be it could be rendering some memory it could be rendering to a GL texture it could be rendering - it doesn't matter it doesn't the result should be the same in the software under yes it would be it'll just create a quick off-screen bitmap you'll render into that and then ttle yeah it'll let it down so it's certainly if this is an OpenGL renderer it'll be a frame buffer so yeah if you do it in core graphics we just tell core graphics to do that I don't know what it does yeah probably I think something quite inefficient judging by some of the performance but but it'll depend entirely on what you're running on so yeah so yeah actually so behind the scenes is it can be a pretty inefficient operation it's like the software and there will be slow because just moving that much memory around is generally a bad thing and especially on the high DPI display actually creating an off-screen bitmap filling it with stuff and then deleting all that moving all that data back into memory we're compositing it can be pretty pretty painful yeah question Rena to image quite a bit so I created a graphics context on the fly with an image as a constructor HM is that happy is creating the graphic context itself is that a heavy operation or creating the graphics context is not heavy but basically free certainly not something you should worry about but creating an image could be yeah especially if the image gets cleared then that you know it's a lot that could be a lot of memory if you if you're doing it in OpenGL to be very fast yeah it's entirely depends on the rendering engine okay so let's look at some more some more rendering operations going back to my component here just put this somewhere we can see it and get rid of my blob again I'm going to quickly look at Pat's because a path is kind of the most the most important shape drawing class that you need to know about behind the scenes if you ask if you called your graphics and so let's draw an ellipse or draw a line or pretty much any anything bits isn't a font or an image behind the scenes it's probably going to create a path and fill the path because most operations do translate down to filling a path so the simple example is let's take a path and let's add an ellipse and let's give it some coordinates paths generally you create them by creating one on the stack and then you'll add some things to it so you might start a sub path and then do some lines or do some quadratics and then end the sub path and then creative a very low-level biasing of building lines or you may say add an add an ellipse or a rectangle or add I think there's a bunch of things like to add star shapes and various different geometric shapes and then you will render it by setting a color or a fill Patten do footpads on the minutes actually let's make it red so you should see appearing that there's a and hands up people who are familiar with how paths work in terms of the inside-outside winding rules and things anyone is that one there okay yeah yeah a few of you but not many when you have complex paths that cross over themselves you're going to get bits of them that where they overlap and we have rules for whether those bits get filled or not it mainly matters we enjoying fonts because glyphs tend to overlap and so she have hop glyphs quite complex without holes in you set winding rules I'm not going to go into too much detail on that but if you're actually when you're actually generating paths by hand you will find that you need to know that kind of thing what I'm going to do here it is illustrated by adding another ellipse so I'm going to take the same path I had before I've added my ellipse which is actually been generated internally by four cubic curves so it's actually basically four four sets of three points the only are the concepts of that path object I'm going to add another one now and I'm going to make this one a bit smaller so this is going to be inside the other one so you're not going to see any difference here because two paths you've got the answer one and the other one it's all it's all becomes one path the whole thing gets filled but when I change the winding rule if I can remember the name of the function for that and I'm just going to have to look up I think word Falls for that then we certainly get a pad for the whole in what this what this is done is that it but why did you have either a zero or non zero zero winding rule associated with a path object and that tells the render of whether it's quite hard to describe but whether as it when it has nested parts of the curve whether whether it they come it whether ones that inside others are also filled or whether it's to alternate the filling and not filling it's it's something you might want to go and have a play with it's kind of kind of fun fun to use if I have another one inside this again that's even smaller then it'll actually come back so let's make one of forty forty fifty fifty and then we've got a circle within a circle but this is actually still only one path each one of these is a separate sub path but when they overlap we've told it to to always go in and so so as its crossing each horizontal line of this path rendering it the rendering engine is going on off on off if I set my winding rule to true then it will be on on on on all the way across it's it's pretty obstacle but it's it's quite a fundamental thing if you actually get into geometry and pass stuff you will whoops that's not that's not going to happen that meeting it's is an important thing to understand next thing you're gonna want to do with the path is to draw an outline around it so we do that with a a stroke type and the graphics context so she has helper methods for this so I can say stroke path and give it a path stroke type say something we can see so this is actually it looks the same as before but this is actually now an outline that's being drawn around the path that I just created so I created my lips it's drawn astir on the path what I'm now going to do is I'm going to change this so it's not an ellipse because the lips is a closed shape I'm going to open shape so we can see that there's actually a line so I'm going to say start a new sub path that's 10:10 and I'm going to draw a line to 100 something I did thank you clang I did mean it's not in use of half so now this is this is a line if you were to just fill that path you get nothing at all so if I do fill path you'll see nothing because it's just the line it doesn't close itself and there's nothing to actually fill but if we stroke it then we do get a stroke and the path stroke type a path straight type class down there it takes other parameters so you can tell it what kind of ends whether you want rounded ends or or and what kind of corners corner joint styles you have so whether you want sharp corners or rounded corners and you've got quite a lot of control over that we also have some dashed paths you'd say let's see so you can have a little crater the full array of dashed lengths so you can say - for 10 pixels then leave a gap of 5 and you can have arbitrary long sequences and then and then you can take a path and - so what happens when you actually draw these things it's some I like to spend a few minutes just giving you an idea of how hard it is to draw these things because it's kind of important when you're when you when you're doing this stuff and trying to optimize your you eyes it's good it's good and I actually would recommend taking a nap and actually just pressing step in to go into a paint routine and just press step into a lot watch going with your debugger just see how far down the rabbit hole these things go and you'll start to get quite a good feel for how how much works involved if you were to call the stroke path function here it's actually going to create another path which is the the outline so it's going to iterate all over the curves of your path it's going to break it all down into the lines it's going to then create some extra lines that go alongside those lines in parallel it's going to join those all into new paths it's going to create a new path object it's going to return that it's going to then pass that on to the graphics renderer graphics renderer is then going to take that path it's going to iterate all the curves it's going to take all those curves and break them down into little line segments it's going to put those all into a big array it's going to sort them all and then it's going to go along for each horizontal scanline each each horizontal pixel it's going to go through that path and it's going to look for all bits of line that cross that horizontal pixel and then it's going to build a little table of one pixel high blocks and it's going to draw them now the if you're using software renderer you can dig and you can you step into this and you'll be there for weeks going down and down this wall building these tables sourcing them building the edge tables and then doing the pixels all the way along here and compositing each of these pixels if you if you watch that what the GL renderer does it does the same but once it gets down to the the horizontal pixel block step it passes those eyes rectangles off to the GPU and that's and that all gets rendered which actually makes the the GL renderer the best way we have currently fought during Pat's because it pretty much works in parallel that CPU is flattening these paths into lines and passing throwing rectangles at the GPU which these are then rendering them as fast as it can so if you run something like our deuce demo which has a which has our rendering demo in it this on this on this page if we have some timing so this is doing some paths and it says during filled with the gradient and this this will be using the core graphics render at the moment it is taking three milliseconds to draw that fairly simple path if I turn on the software renderer actually better which is surprising but this is on a low res display this was on my rest on display didn't they were prob'ly the other way around because we've got a lot of pixels and the software renderer is really efficient on rendering small things because there's no overhead of talking to a GPU it just sets a few pixels in memory and you're done but when you have big big high pixel density displays the numbers just get really crazy and the software ender is never gonna be very good the GL renderer is kicking ass here it's down to not point five milliseconds and it's basically using exactly the same path as the software renderer except when it hits the compositing stage and the compositing stage all of the gradients the colors within these gradients are being rendered by GPU shaders and all of the horizontal pixel lines are being just thrown at GPU for rendering GPU right my question is are the paths are all converted to rectangles yeah but if you could do very small rectangles yeah yeah but did you could do those doesn't have to have rectangles the GPU but you don't have to enter the GPU can do it if you have if you're using something like CUDA or OpenCL what what the GPU can't do or at least I've never managed to figure out a way of doing with with with a normal GL shader is taking a curve and rasterizing it and then turning that into scan lines because it's it has to simple okay another another approaching take with a with GL would be to triangulate it if you triangulate it which was how I originally did this it's fine it'll work but you'll get very poor anti-aliasing yeah just the SPRO and what I wanted with with the gctv renderer was to make something that was actually pixel for pixel the same as the software and the and the core graphics renderer and for that the only way I could find to do it until the next generation graphics api's came along pretty soon is to actually do the anti-aliasing manually by the CPU so though even though you can't see on here like the actual anti-aliasing around the edges of these are actually done but as one pixel rectangles and then larger pixels for the solid bit and that's how the software and there's already always done it and it works pretty well and on the GL renderer I mean the performance is very good it could be even better if we have with within the next generation API was like Vulcan and metal I'm hoping or we going to be able to write something where you just throw the whole Bezier curve path at the GPU and let it do it in parallel yeah I don't know as I there will be a specific that would be fairly cross-platform but kind of like you can you can almost do this with GL shaders but not quite I'm actually quite looking forward to that playing around without this year that's a lot that's somewhat a road map last question do you have an idea why these core graphics is being outperformed by yourself or graphics around right well this is because of all the system calls you know if I put it on the other display it might be different I don't know what's going on in that um no that's what I always noticed between our Windows and Mac version the Windows version rendering is really quick make it will also depend what you throw at it I mean the core graph is very very good it's just sentence certain cases you're gonna find one one methods favorite and yeah like for example with a solid if I do solid color it might be different yes our color we got GL render 0.3 cool graphics render points point 8 software into 0.5 they're all pretty close you'll get you will get differences when we when you were in the in images because okay we've got a software renderer will always be terrible at rendering images because just moving all that data back and forth is going to be very difficult and CPUs are really bad that the sub sampling you need to do to filter that images as you as you rotate them the so we're getting actually in this case it's always quick that's what is doing very well yeah the core graphics is similar the core guys behind the scenes for that image is probably doing it in memory because it's not if you use a core animation they don't because the OpenGL will wipe the floor with all of them in this case because what's happening here is the image in the juice image classy there's a flag to say whether the image has been changed if you draw an image to the GL context it has to upload the data so it'll upload it to a GL texture and we'll use that to render it but then it keeps track of that texture so that if it knows next time you draw the same image if it knows it hasn't changed and if it's still got that texture on on the GPU it'll just reuse it so actually this thing is cheating because every time it draws this it the data is already on the GPU there's absolutely nothing no traffic going back and forwards so all it has to do is is draw with the existing texture and on GL to actually draw an image and subsample it is kind of that's just what they do it's the chip is designed for that so you're going to get blistering performance out of that it's even faster with the RGB tiling here which is practically zero the reason during a single image is slower than drawing a tiled image is because when we draw a single image we want anti-alias edges and because we're doing that fine chance for oneness if you're just drawing an image as a fixed size and there's no there's there's no need for anti-aliasing around the edges then we can optimize but in this case this is actually drawing it as horizontal lines like a path it's basically taking a path a rectangular path I find transforming that and filling it with this as filling that filling it with that almost like an image texture so that's actually this is actually although it's going very fast especially a pretty pretty slow operation behind the scenes some rectangles very simple to do what the so software 1.2 core graphics 3i congressional is normally better sorry okay so we already started talking about image yourself but I think maybe carry on with that we've got to finish in 10 minutes so I want to get through a few things images like I say then that you can you can have different modes of using they keep they can be in memory which is great for the software renderer they could be in GL memory if you're using a gel renderer and you can you can explicitly create an OpenGL image using OpenGL image type so if you want to force forcibly get a frame buffer and draw into it you can do that and if you get a OpenGL frame buffer image and create a graphics to draw into it that will use GL to draw into the into the image other stuff I should cover in the arraigns I got some glyphs being drawn here in this let me see that the forces on here this is a case where you're going to get the most like like I said before the most difference between the different rendering engines so the cool graphics stuff will probably look better because they have some very clever algorithm I can't quite quite figure out our software and GL renderers we now are in the fonts after years of me being hassled on the forums about juices blurry font rendering it's not blurry it's simply correct but ok I get it at some some some font sizes yeah ok it's a bit blue at some bottom so what we did I think maybe a year or two ago is came up with a new rendering algorithm where we fix the we snap the fonts vertically so that by looking at the height of upper and lowercase letters so we'll look at like an uppercase H and n and things with flat tops and we'll look at like the lowercase ends and ends and look at whether where the horizontal midline is and then we snap all very slightly by under a pixel will fit the font to the on-screen pixels so the top and bottom lines and hopefully the bars in the middle of like a capital e will all snap nicely onto solid pixels and then horizontally we keep everything sub-pixel so that when you see whole words and hold the whole sentences it doesn't look all wonky like you get on old-fashioned windows which i've always hated so that that's how we render it in the software in GL engines the core graphics already did as a wonderful job and does seem to do something fairly similar as well as they seem to for small font slices they seem to pad out the thicknesses of the characters as well somehow in terms of drawings fonts text we've got several light levels you can you can go out so you can either get your graphic subjects and say draw some text put it here in this font which is fine or you can create a glyph arrangement object which is based a glyph arrangement is a set of font of font glyphs all laid out in a particular layout so that could be a page of text you'll have a glyph arrangement which is a whole page of text and then you can reuse that glyph arrangement say just draw it draw it draw this glyph arrangement move it around and if you're redrawing the same thing many times that can be more efficient behind the scenes if you just draw some text it will secretly create a glyph arrangement enjoy it for you but you can manually create one and move it and keep it keep it around we also have a text layout class which is an even higher level where you say here's some attributed strings where you give it so here's a string of text with some colors and fonts and you can build up strings of different types of fonts and text and then say lay it out with this width and that objects a text layout and then you can reuse those as well and those are used internally for things like the text editor and other text editing classes and SVG is another good one here we have a full SVG parser and this whole set of classes behind the scenes to to manipulate them so if you if you want to load some SVG the class uses the durable class I haven't really got time to dig into durables I hoped I would but the drawable is a type of a special type of component there are only a few types of drawable we have a durable path we have a drawable image we have a durable composite which is assessable durables and these things when you when you pass some SVG you throw some SVG SVG file at the parser it will give you back a durable that drawable is a component you can just add it to the screen so that's what's going on in this demo here is it's just throwing a component in here and moving the components around within that one transport but all the sub parts being drawn so all of the all of the colored subsections of these images are a nest of other durable components inside each other unlike normal components these are a bit different because they they own the child components if you write a normal normal component you you're responsible for deleting your child components but if you have a drawable everything within it is own so you can treat the drawable almost like a pipe by value type you can pass them around you can copy them you can delete them and it's just like a thing like any kind of like an image but it's shapes this this means you can pass some SVG and then do things to it because you've got the whole SVG graph there as a drawable so you could iterate through this graph and change colors change positions of things within it do the things add these things together and do all kinds of high level manipulations on earth something came up recently for ms some people have been trying to inherit from drawables which is not how they're intended to be used other components you inherit you override things you do add custom behavior the drawable classes are meant to be used just as is you don't inherit you can posit them you put them together you use them to build shapes like this and then you draw that shape and there's a bunch of places we use these these around the code base so you can have a job or image drawable button where you give it a drawable to use and that's replace instead of an image so you'd have a complex SVG shape and that's your that's your button very easily and we music a bunch of other things quite a handy trick in the in the introducer or producer is we actually have a little SVG path converter here which is because we've got lots of SVG parsers in there this lets you easily take an SVG path and turn it into a bunch of code which generates a normal juice path so you can paste in stuff from an SVG file from the internet and sew it to a path and then do whatever kind of juice rendering tricks you need to get that path onto the screen okay I think because it's getting so noisy and Sonia we've got five minutes left I better stop and open up for questions before we before we go any further pointer Chris if you if you need if you need the mic yes people identify so yes yeah yeah yeah give a brief introduction if you're all right yeah but we make VJ software called resolute and we use juice quite heavily for for years and years be I think since 2000 I guess it's a long time already so my question was is that we have a lot of sliders like and how can we is a way to optimize it because it uses past everywhere for trawl in your slider drawer whatever is there because she said but if you step into it it's quite heavy would that be a way to rebrand the parts or whatever because if the slides always the same size you can't rerun the pattern pre-rendered paths and actually in I I wouldn't recommend trying because actually drawing a path is probably faster than drawing an image that of a path on almost all platforms other than on GL where you where your statically generating an image and then rendering it many times which will be faster but most more memory hungry the one thing I really should say because this is a performance talk about performance and graphics efficiency I've gone all this way without mentioning profile it if you if you if you've got a performance problem first thing you do is profile yeah but you said you mentioned depart they step into there's quite a bit of work and you just talking about the paths of how much work it is yeah exactly it's going to be heavier than cigarettes are a lot of work but during an image is although it's simpler it's actually much generally much harder for the processor because you're gonna hit you're gonna have caching problems you you just moving all that memory about is going to immediately be a big deal for the CPU this never used to be true in the past like years ago when we had a lower resolution displays everything's fine because it's a small manageable amount of memory but now you get high DPI displays and these things are just off the charts amount of memory by using this sort of set buffer to image thing wouldn't be befits an image is a component method yeah which this is drawing to it to an image that were that may or may not be faster depending on the size of the component and how often it's drawn and and it's one of these things like performance these days there are no there are no easy answers you've got a you've got a profile it an a/b it certainly is it's always worth trying the the sit there buffer to image stuff and there's actually another level you can go to you with buffering two images I didn't have time to get onto this in they can put it but this is a component trick high-level pro pro tip which is components you can say buffer themselves to an image if you're really advanced you can create your own buffering to image methods that you can attach to a component so you can say you can actually add a little class in between the component rendering itself and being repainted such that if you want to buffer to a special kind of image or you've got some sort of weird crazy algorithm you can actually intercept the paint and the repaint calls for a particular component and do whatever you need to do this is actually how the that all of the OpenGL to the rendering done by attaching these special rendering interceptors to components and it actually renders it OpenGL rather than rendering it in a normal pipeline so that I mean they took from it for an hour about that but yeah whether it be useful for you in spends entirely on what you're doing but for certainly for we've done a lot of performance optimization interaction which is obviously a pulse people always fullscreen it you up all these complicated yeah everything's flying around so we've we've spent a lot of time staring at profilers and you can often find some interesting low-hanging fruit in that no won't be interesting as a blog post we did this what we had and it's what we did to to to Pro to to we profile we saw this happening that will be interesting for us to say well if they if you have a project that is a bit like what we did yeah these are the things you can think about yeah I'm benefits because the big just gained we had with traction was when we went to painting his unclipped when we turned all the clipping off so that these things were basically getting rendered bang just all these all these nested Clips just being rendered with no with it without the overhead of saving loadings the graphics tape right that seems to be the big big bottleneck for us surprisingly and the paths generally are pretty even though it's be very very complicated it tends to be pretty cheap and certainly if they're big a big path will be much faster than the big image small path small image the lines get blurred okay thanks any other questions okay no one on the back so it's also about rendering GUI performance we just have the exact opposite of UI with lots of images to render one for each knob and currently we are trying to optimize this to being to display on high DPI dpi and stuff like that we are using set buffer to image we haven't tried the gr underwear so you think I would nicely if you're dealing with images the GL render will almost certainly be faster because even for even if you're changing image every time you draw it which you probably aren't the the time to push it to the GPU memory and as a texture and then draw it seems to be better than just listing it around with with CPU so definitely I mean this would be very easy to swap the render is out you can you know you can change that and in the same way in the demo in the G stemmer you can you would flip between them it just just try them out and see what see what the numbers look like okay yeah it's definitely worth trying

Channel: JUCE

Views: 7,787

Keywords: JUCE Summit, Julien Storer, C++, GUI, VST, AudioUnit, Plug-ins, OpenGL, SVG, Opacity, Programming, Graphics, Code

Id: hvIcczswccI

Length: 49min 36sec (2976 seconds)

Published: Mon Aug 15 2016