Re: Media API question regarding metadata retrieval
On Wed, Apr 1, 2015 at 10:50 PM, Scott Palmer swpal...@gmail.com wrote: I seems like a decent compromise to defer to the native platform code that will ultimately be used to process the file anyway. It seems a little heavy, but the alternative is perhaps bloating the JavaFX API. Yes absolutely but ... (see my reply to David). It likely makes more sense to use the MediaInfo project with some JNA bindings (you can probably find either JNI or JNA bindings on the web) if you need access to the metadata: https://mediaarea.net/nn/MediaInfo Yes, also agreed for real general-purpose metadata retrieval like in a broadcast or media converter product, it does not make sense to kick off such a huge project in Java, when there is already native code around for that and we are doing that already in one of our products using JNI. I am talking about the super-simple cases where I am fine with the (very limited) format support of JavaFX and I just want to know duration, width and height basically for those files and I do not want to ship native libs with my cross-platform app which otherwise works well enough with pure Java. I just don't see any technical reason to instantiate a player for that in any native framework I know and it should not be necessary in JavaFX IMHO. Of course I can wrap all that in my own library and probably will and then the fact that a player is instantiated and then thrown away is just an implementation detail, I just did not and still do not see why this is necessary or sensible, which is why I asked. I keep thinking a pure java port of MediaInfo would be cool... but probably not worth the time :-) Yes, I agree and it's doable but A LOT of work (if you want to have the level of completeness and maturity of MediaInfo) and therefore not likely to happen anytime soon.
Re: Media API question regarding metadata retrieval
On Wed, Apr 1, 2015 at 9:48 PM, David DeHaven david.deha...@oracle.com wrote: I was a bit surprised that the metadata retrieval functionality of javafx.scene.media.Media is only usable in conjunction with a player, so if I want to retrieve the dimensions of a video file I have to instantiate a player and wait for it to reach ready state? That's how I read the javadoc. Is this a misunderstanding? Nope, currently you have to create a player. Once a player is created it kicks off a parser to grab metadata or waits for the underlying native player to parse. If not is there a specific reason not to offer this functionality independently of a player? There were plans, there were also issues as we don't have a Java based mp4 parser so we're relying on the underlying platforms (e.g. QTKit, AVFoundation, etc..) to provide that data, which basically means we're creating a player at the native level anyways. If you're using the horribly outdated FXM format you get the benefit of a Java Deferring to native code absolutely makes sense but I didn't think that you needed to create a player to obtain duration, width and height in AVFoundation either.
Re: Canvas performance on Mac OS
On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw. Are you running a newer version of MacOS? ...jim On 3/31/15 3:40 PM, Chris Newland wrote: Hi Hervé, That's a valid question :) Probably because a) All my non-UI graphics experience is with immediate-mode / raster systems b) I'm interested in using JavaFX for particle effects / demoscene / gaming so assumed (perhaps wrongly?) that scenegraph was not the way to go for that due to the very large number of nodes. Numbers for my Sierpinski filled triangle example: System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M 1024 MB java -Dprism.order=es2 -cp target/classes/ com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 23 fps: 18 fps: 25 fps: 18 fps: 23 fps: 23 fps: 19 fps: 25 java -Dprism.order=sw -cp target/classes/ com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 54 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 There are never more than 2500 filled triangles on screen. JDK is 1.8.0_40 I would say there is a performance problem here? (or at least a need for documentation so as to set expectations for gc.fillPolygon). Best regards, Chris On Tue, March 31, 2015 22:00, Hervé Girod wrote: Why don't you use Nodes rather than Canvas ? Sent from my iPhone On Mar 31, 2015, at 22:31, Chris Newland cnewl...@chrisnewland.com wrote: Hi Jim, Thanks, that makes things much clearer. I was surprised how much was going on under the hood of GraphicsContext and hoped it was just magic glue that gave the best of GPU acceleration where available and immediate-mode-like simple rasterizing where not. I've managed to find an anomaly with GraphicsContext.fillPolygon where the software pipeline achieves the full 60fps but ES2 can only manage 30-35fps. It uses lots of overlapping filled triangles so I expect suffers from the problem you've described. SSCCE: https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/com/ch risnewland/demofx/standalone/Sierpinski.java Was full frame rate canvas drawing an expected use case for JavaFX or would I be better off with Graphics2D? Thanks, Chris On Mon, March 30, 2015 20:04, Jim Graham wrote: Hi Chris, drawLine() is a very simple primitive that can be optimized with a GPU shader. It either looks like a (potentially rotated) rectangle or a rounded rect - and we have optimized shaders for both cases. A large number of drawLine() calls turns into simply accumulating a large vertex list and uploading it to the GPU with an appropriate shader which is very fast. drawPolygon() is a very complex operation that involves things like: - dealing with line joins between segments that don't exist for drawLine() - dealing with only rendering common points of intersection once To handle all of that complexity we have to involve a rasterizer that takes the entire collection of lines, analyzes the stroke attributes and interactions and computes a coverage mask for each pixel in the region. We do that in software currently for all pipelines. For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs CPU path rasterization. For the SW pipeline, drawLine is a simplified case of drawPolygon and so the overhead of lots of calls to drawLine() dominates its performance. I would expect ES2 to blow the SW pipeline out of the water with drawLine() performance (as long as there are no additional rendering primitives interspersed in the set of lines). But, both should be on the same footing for the drawPolygon case. Does the ES2 pipeline compare similarly (hopefully better than) the SW pipeline for the polygon case? One thing I noticed is that we have no optimized case for drawLine() on the SW pipeline. It generates a path containing a single MOVETO and LINETO and feeds it to the generalized path rasterizer when it could instead compute the rounded/square rectangle and render it more directly. If we added that support then I'd expect the SW pipeline to perform the set of drawLine calls faster than drawPolygon as well... ...jim On 3/28/15 3:22 AM, Chris Newland wrote: Hi Robert, I've not filed a Jira yet as I was hoping to find time to investigate thoroughly but when I saw your question I thought I'd better add my findings. I believe the issue is in the ES2Pipeline as if I run with -Dprism.order=sw then strokePolygon outperforms the series of strokeLine commands as expected: java -cp target/DemoFX.jar -Dprism.order=sw com.chrisnewland.demofx.DemoFXApplication -c 500 -m line Result: 44fps java -cp target/DemoFX.jar -Dprism.order=sw com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly Result: 60fps Will see if I can find the root cause as I've got plenty more examples where ES2Pipeline performs horribly on my Mac which should have no problem throwing around a few thousand polys. I realise there's a *lot* of indirection involved in making JavaFX support such a wide range of underlying
Re: Canvas : 2 pixel thick line width
Hi Damien, The main problem is that the definition of a stroked path and the definition of a filled path are at odds. If the default stroke width is 1.0 and the default stroke type is CENTERED, then the stroke is centered on the outline of a path and half of it falls on either side of the outline. For those defaults, if you have the coordinates at pixel centers then integer coordinate fills end up with fuzzy sides (and basic rectangle fills are the most common operation in any system) even though that may help stroked lines and paths. If you have the coordinates at pixel edges then integer fills are nice and crisp and you then only need to adjust for stroked shapes. (Note that on a retina screen with 2x pixels you get both crisp fills and strokes either way, so all hail the new HiDPI world. ;) For non-AA rendering you actually don't get any fuzziness since only whole pixels are included or not, but you do have the phenomenon of coordinate stability. If you compute an outline and you are off by just a few rounding bits and your coordinates are at the same location as your sampling points then your shape shifts. If the coordinates are halfway between the sampling points then a few bits of rounding will not affect the shape. Our default is center of pixel sampling, as it is with most rendering systems, so having integer coordinates halfway between them (i.e. at the edges of pixels) makes sense for non-AA. Java2D has a concept called stroke control which applies some rounding process to all coordinates so as to help them end up creating crisper outlines, but it has its drawbacks - particularly in the fact that it fights your ability to have a nice round circle or oval since this concept of shifting points fights the exact geometry involved in the control points of perfectly round shapes. When we were first creating FX we decided that: - stroke control created some problems that we'd like to avoid even if it does provide some security for new programmers - the vast majority of control styling was shifting to using concentric filled backgrounds rather than strokes so the fact that default strokes can be fuzzy was a non-issue for the controls team - we introduced the concepts of inner and outer strokes which play better with outlining controls than the typical graphics library's default of centered strokes and they have similar needs of where integer coordinates should be placed to avoid fuzziness as fills do - it is time to advance this issue to an exposed one where developers will need to be cognizant of our rasterization rules and stroke geometries to render correctly. This should be documented better, though. That much is true... ...jim On 4/1/15 3:14 AM, Damien Dudouit wrote: Hello, I have found the following answer : http://stackoverflow.com/questions/27846659/how-to-draw-an-1-pixel-line-using-javafx-canvas *Imagine each pixel as a (small) rectangle (instead of a point). The integer coordinates are the boundaries between pixels; so a (horizontal or vertical) line with integer coordinates falls between pixels. This is rendered via antialising, approximating half of the line on one pixel and half on the other. Moving the line 0.5 pixels left or right moves it to the center of the pixel, getting around the issue.* I have done quite a bit of custom controls drawing (canvas) with swing and swt and it's quite a shift of approach that plain coordinates to not match pixels on display. In swing/swt, if I want to draw a rectangle from pixel (0,0) to pixel (2,2), ie. a square of 3x3 pixels I do : gc.drawRectangle(0, 0, 3, 3); // x, y, width, height In JavaFX I must do : gc.strokeRect(0.5, 0.5, 2, 2) Have a good day, Damien 2015-04-01 11:42 GMT+02:00 Damien Dudouit ddudo...@clio.ch: Hello, I'm using a Canvas to display some content (mostly text with lines also for underline). I've just noticed something that is a big problem for me : with line-width=1 and no scaling, actual line-width on display takes 2 pixels. Canvas canvas = new Canvas(300, 300); GraphicsContext gc = canvas.getGraphicsContext2D(); gc.setStroke(Color.BLACK); gc.setLineWidth(1); gc.strokeLine(10, 10, 110, 10); I'm running Win7 64bits and I have made the test with Oracle jdk8_40 and jdk7_71 and the result is the same. That 2 pixel thick line is not perfectly black but dark gray. If I do 'gc.setLineWidth(2)', then I get a 2 pixel thick line perfectly black. If I do 'gc.setLineWidth(0.5)', then I get a 2 pixel thick line with a lighter gray. I want to display underline text in the canvas and a 2 pixel thick underline looks bad. Any help would be greatly appreciated. Damien
[8u60] Review request: RT-40184 - Remove use of internal classes methods from samples
Hi Kevin, Chien, Please review fix for https://javafx-jira.kenai.com/browse/RT-40184 Link to webrev: http://cr.openjdk.java.net/~ekleyman/RT-40184/ Thanks, Elina
Re: Media API question regarding metadata retrieval
If not is there a specific reason not to offer this functionality independently of a player? There were plans, there were also issues as we don't have a Java based mp4 parser so we're relying on the underlying platforms (e.g. QTKit, AVFoundation, etc..) to provide that data, which basically means we're creating a player at the native level anyways. If you're using the horribly outdated FXM format you get the benefit of a Java Deferring to native code absolutely makes sense but I didn't think that you needed to create a player to obtain duration, width and height in AVFoundation either. No, but for the lack of a separate interface for metadata retrieval. In hindsight there were a number of things that should have been done differently :/ -DrD-
Re: Media API question regarding metadata retrieval
If not is there a specific reason not to offer this functionality independently of a player? There were plans, there were also issues as we don't have a Java based mp4 parser so we're relying on the underlying platforms (e.g. QTKit, AVFoundation, etc..) to provide that data, which basically means we're creating a player at the native level anyways. If you're using the horribly outdated FXM format you get the benefit of a Java Deferring to native code absolutely makes sense but I didn't think that you needed to create a player to obtain duration, width and height in AVFoundation either. No, but for the lack of a separate interface for metadata retrieval. In hindsight there were a number of things that should have been done differently :/ Alright, understood. No offense intended btw.. Thanks for taking the time to explain! None taken! :) Happy to help when I can. -DrD-
Re: Media API question regarding metadata retrieval
On Thu, Apr 2, 2015 at 6:16 PM, David DeHaven david.deha...@oracle.com wrote: If not is there a specific reason not to offer this functionality independently of a player? There were plans, there were also issues as we don't have a Java based mp4 parser so we're relying on the underlying platforms (e.g. QTKit, AVFoundation, etc..) to provide that data, which basically means we're creating a player at the native level anyways. If you're using the horribly outdated FXM format you get the benefit of a Java Deferring to native code absolutely makes sense but I didn't think that you needed to create a player to obtain duration, width and height in AVFoundation either. No, but for the lack of a separate interface for metadata retrieval. In hindsight there were a number of things that should have been done differently :/ Alright, understood. No offense intended btw.. Thanks for taking the time to explain!
