On Wednesday, 27 April 2016 at 12:42:05 UTC, thedeemon wrote:

>  full build of GUI app takes 7 seconds

Forgot to mention one anecdote:
the build time increases by another 7 seconds if I use std.net.curl.get() function instead of std.net.curl.HTTP struct for doing a simple GET from our site.

On 04/27/2016 01:17 PM, thedeemon wrote:
> On Wednesday, 27 April 2016 at 12:42:05 UTC, thedeemon wrote:
>
>>  full build of GUI app takes 7 seconds
>
> Forgot to mention one anecdote:
> the build time increases by another 7 seconds if I use
> std.net.curl.get() function instead of std.net.curl.HTTP struct for
> doing a simple GET from our site.

What is the reason for this, could you please investigate a bit? -- Andrei

On 4/27/2016 5:42 AM, thedeemon wrote:
> I just wanted to share some experience of using D in industry.

Wonderful, thanks for taking the time to write this up. I'm especially pleased that you found great uses for a couple features that were a bit speculative because they are unusual - the user defined attributes, and the file binary data imports.

On Wednesday, 27 April 2016 at 12:42:05 UTC, thedeemon wrote:
> Hi,
> I just wanted to share some experience of using D in industry.
> Recently my little company released version 2.0 of our flagship product Video Enhancer, a video processing application for Windows, and this time it's written in D.
> http://www.infognition.com/VideoEnhancer/

Awesome work, congratulations!

Can you share with us some of your experience working on image and video processing modules in the app, such as are filters here:
http://www.infognition.com/VideoEnhancer/filters.html

If I may ask, was that part implemented in D, C++, or was some 3rd party library used?

Thanks, and again - big congrats!
Relja

On Thursday, 28 April 2016 at 06:22:18 UTC, Relja Ljubobratovic wrote:

> Can you share with us some of your experience working on image and video processing modules in the app, such as are filters here:
> http://www.infognition.com/VideoEnhancer/filters.html
>
> If I may ask, was that part implemented in D, C++, or was some 3rd party library used?

Thanks!

The filters listed there are third-party plugins originally created for VirtualDub ( http://virtualdub.org/ ) by different people, in C++. We made just 2-3 of them, like motion-based temporal denoiser (Film Dirt Cleaner) and Intelligent Brightness filter for automatic brightness/contrast correction. Our most interesting and distinctive piece of tech is our Super Resolution engine for video upsizing and it's not in that list, it's built-in in the app (and also available separately as plugins for some other hosts). All this image processing stuff is written in C++ and works directly with raw image bytes, no special libraries involved. When video processing starts our filters usually launch a bunch of worker threads and these threads work in parallel each on its part of video frame (divided into horizontal stripes usually). Inside they often work block-wise and we have a bunch of template classes for different blocks (RGB or monochrome) parameterized by pixel data type and often block size, so the size is often is known at compile-time and compiler can unroll the loops properly. When doing motion search we're using our vector class parameterized by precision, so we have vectors of different precision (low-res pixel, high-res pixel, half-pixel, quarter-pixel etc.) and type system makes sure I don't add or mix vectors of different precision and don't pass a half-pixel-precise vector to a block reading routine that expects quarter-pixel precise coordinates. Where it makes sense and possible we use SIMD classes like F32vec4 and/or SIMD intrinsics for pixel operations.

Video Enhancer allows chaining several VD filters and our SR rescaler instances to a pipeline and it's also parallelized, so when first filter finishes with frame X it can immediately start working on frame X+1 while the next filter is still working on frame X. Previously it was organized as a chain of DirectShow filters with a special Parallelizer filter inserted between video processing ones, this Parallelizer had some frame queue inside and separated receiving and sending threads, allowing the connected filters to work in parallel. In version 2 it's trickier, since we need to be able to seek to different positions in the video and some filters may request a few frames before and after the current, so sequential pipeline doesn't suffice anymore, now we build a virtual chain inside one big DirectShow filter, and each node in that chain has its worker thread and they do message passing to communicate. After all, we now have a big DirectShow filter in 11K lines of C++ that does both Super Resolution resizing and invoking VirtualDub plugins (imitating VirtualDub for them) and doing colorspace conversions where necessary and organizing them all into a pipeline that is pull-based inside but behaves as push-based DirectShow filter outside.

So the D part is using COM to build and run a DirectShow graph with all the readers, splitters, codecs and of course our big video processing DirectShow filter, it talks to it via COM and some callbacks but doesn't do much with video frames apart from copying.

Btw, if you're interested in an image processing app in pure D, I've got one too:
http://www.infognition.com/blogsort/
(sources: https://bitbucket.org/infognition/bsort )

Awesome! Thanks so much for such detailed explanation!

> Btw, if you're interested in an image processing app in pure D, I've got one too:
> http://www.infognition.com/blogsort/
> (sources: https://bitbucket.org/infognition/bsort )

Great, I'll check it out - Thanks!

On Wednesday, 27 April 2016 at 12:42:05 UTC, thedeemon wrote:
> Hi,
> I just wanted to share some experience of using D in industry.
> Recently my little company released version 2.0 of our flagship product Video Enhancer, a video processing application for Windows, and this time it's written in D.
> http://www.infognition.com/VideoEnhancer/
>
[snip]
>
> DLangUI
> Very nice library. Documentation is very sparse though, so learning to use DLangUI often means reading source code of examples and the lib itself, and sometimes even that's not enough and you need to learn some Android basics, since it originates from Android world. But once you learn how to use it, how to encode what you need in DML (a QML counterpart) or add required functionality by overriding some method of its class, it's really great and pleasant to use. Many times I was so happy the source code is available, first for learning, then for tweaking and fixing bugs. I've found a few minor bugs and sent a few trivial fixes that were merged quickly. DLangUI is cross-platform and has several backends for drawing and font rendering. We're using its minimal build targeted to use Win32 API (had to tweak dub.json a bit). We don't use OpenGL, as it's not really guaranteed to work well on any Windows box. Using just WinAPI makes our app smaller, more stable and avoids dependencies.
>
[snip]

Another reason to embrace DLangUI. One starting point would be to improve the documentation and write a few tutorials (including DML, themes etc.)

On 2016-04-28 01:53, Walter Bright wrote:

> Wonderful, thanks for taking the time to write this up. I'm especially
> pleased that you found great uses for a couple features that were a bit
> speculative because they are unusual - the user defined attributes, and
> the file binary data imports.

I'm using the string import feature in DStep to bundle Clang internal header files. It's a great feature that makes distribution a lot easier since only a single executable is everything that is needed.

-- 
/Jacob Carlborg

On Wednesday, 27 April 2016 at 12:42:05 UTC, thedeemon wrote:
> Cerealed
> This compile-time-introspection-based serializaition lib is really great: powerful and easy to use. We're probably using an old version, haven't updated for some time, and the version we use sometimes had problems serializing certain types (like bool[], IIRC), so sometimes we had to tweak our message types to make it compile, but most of the time it just works.

Thanks for the kind words! Can you let me know what was wrong with serialising bool[] and whatever other types you had problems with please? I'd like to fix them. Thanks!

Atila

On Wednesday, 27 April 2016 at 12:42:05 UTC, thedeemon wrote:
> (snip)

Sorry to bump this thread, but how did you handle multiple windows using DlangUI? (As in, were you able to prevent input on the main window while another one was open, etc.) I know Vadim/buggins is working on improving that right now but I'd like to know if there's a clean way to handle more than one window already.