Phobos colour module?

Manu via Digitalmars-d digitalmars-d at puremagic.com
Fri Jan 2 00:46:17 PST 2015


On 2 January 2015 at 08:21, Brad Anderson via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via Digitalmars-d wrote:
>>
>> [snip]
>> Thoughts?
>
>
> I don't think something like this belongs in phobos. It's not universal
> enough to warrant all the extra work it would require to add and maintain in
> phobos.

Not universal enough? Colours are not exactly niche. Loads of system
api's, image readers/writers, icons, they all use pixel buffers.
A full-blown image library will require a lot more design work, sure,
but I can see room for that in Phobos too. There are a lot of tasks
that you can't really just download D and get to work on, particularly
in the realm of UI and multimedia, which are important tasks.


> There are significant advantages to doing it as a dub project:
>
> - Not being locked into phobo's irregular update cycle
> - Making use of other third party libraries
> - Easier to control how it is built (the distributed phobos isn't even built
> with inlining enabled currently)
> - Easier to accept pull requests for cases where the author isn't a phobos
> committer
> - Much more freedom to break code while still letting people use an old
> version if they can't do the necessary updates for whatever reason
>
> I'd love having access to something like this though. My own color stuff is
> always cobbled together from code gathered from random websites and I'm
> rarely confident I implemented them correctly or efficiently.

Yeah, it's probably actually the hardest part of image processing
jobs, and it's also the least debatable about what's 'right'. The
layers that could be built on top could be varied and remain fairly
lean.


More information about the Digitalmars-d mailing list