-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Øyvind Kolås wrote: | * Jelle Herold <jelle@xxxxxxxxx> [031127 22:12]: | |>Hi, |> |>I've been following this list for a while, and experimenting some |>with gegl. Now, my question is how well suited is (or rather, will be) |>Gegl for realtime 2D graphics. I need to build processing graphs such as |> |>some ffmpeg decoders -> transformations, masks, convolutions -> sdl display |> |>the graphs may end up quite large and the filter parameters will be |>changed almost every step, the resultion is low/normal (eg. 640x480). |> |>Or will I be better off using something like the OpenGL Imaging path? | | | short version: | | for advanced processing, with todays technology,. probably no. | | long version: | | This will of course depend on both the complexity of the graph, and the | hardware available. Hardware acceleration of gegl is an isssue that | hasn't been discussed much, but it would be nice if the architecture | allowed using opengl in the special cases where it would be feasible. Well, yes, I haven't thought much about hardware acceleration, though it is something that should be thought about much more later. It is a post-gimp-itegration topic, I think. | Is this a really large workload? computing the raw image sizes assuming | a full noninterlaced PAL transmission,. 720x576 rgba 8bit unsigned, 25 fps. | a raw frame is 720 * 576 * 4 * 25 = 41472000 bytes/sec | = 40500 kbytes/sec | = 39.551 mbytes/sec | = 316.41 mbit/sec Well, gigabit networks are comming down in price a lot, so I doubt someone doing realtime image processing would limit themselves to 100Base-T, but even if you did, you could still construct N-Way connected networks with much higher bandwidth and 100 mbit/sec. Further you could partition the network so that each portion of the network is processing a certain region or set of tiles. Also, lets try not to talk about i1080 Progressive Scan HDTV. | At that rate I realize that clustering of machines in a 100mbit network, | would not work :(, unless you implement compression on the data, which | also is unlikely Naw, not that unlikey. At the very least one could do RLE at each end with little to no overhead, but if you are bandwidth limited, and thus not utilizing your full processor, then compression might be a big gain. But a more pertainate answer is that hardware acceleration and network rendering are very much on my mind. Playing with these ideas is the whole reason I got interested in gegl. I can hardly wait until gegl reaches this point. - -- Dan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/xoy7ad4P1+ZAZk0RAtgFAJwKVH47JMI7mGydMNcMTq48yxHSNgCfdU2h NP0fLJtvnzmh9vnV1XFS198= =czhM -----END PGP SIGNATURE-----
