Rick Brewster

Please do not ask for the source code. If or when all or part of it becomes available, you'll see it on the website and the blog. (Although its very unlikely I'll publish all of it.) Thread Closed

No. I'm not rewriting the whole app everytime some new UI technology comes out. There would be no end-user benefit. And no, before you ask, I'm not rewriting it in Silverlight. Or ASP.NET. Or Cocoa. Or Flash.

Please edit your thread title -- see [rule=6]rule #6[/rule] for the reason why.

The choice was between running a greyscale filter over a ClearType render, or letting it not use any antialiasing at all, or using supersampling in a way that would drive performance down to the floor (except on a $10,000 computer). ClearType does not belong on bitmaps; it is only for rendering UI text. You have to trust me that I've chosen the best strategy given what was available. I never said there weren't trade-offs. Umm... That's generous of you, but it's just not going to happen. It wouldn't even matter if we were in complete agreement. 3.5 is locked down and in strictly bug-fix mode, and what we are discussing here isn't a bug -- it is by design. Shipping is a feature too.

Paint.NET v3.5, internally*, has a notion of lazy-evaluation surfaces via the IRenderer interface. It's inspired by LINQ, and lets you do something like ... // s0 and s1 are surfaces var s2 = s0.Resample(s0.Width / 2, s0.Height / 2, Bicubic).BlendWith(s1, OverlayBlendOp); // similar to using LINQ operators, Select() Where() etc. // At this point no pixels have been computed, and no bitmaps have been created s2.RenderTo(s3, new Int32Point(x, y)); // region of interest is (x,y) with s3.Width,s3.Height for size s2.ToSurface(...); // analagous to LINQ's ToArray() Basically, IRenderer is analagous to IEnumerable, and Surface is analagous to Array. * Technically these are public and exported from PDN.Core. However, they are not meant for plugin's use. At least not yet.

The property accesses on Rectangle are the least of your troubles. All that Rectangle.get_Left() does, for instance, is "return this.X;". That will be inlined. I'm not sure what you mean by this. It'd be news to me if it were transforming code.

You shouldn't spend much time in OnSetRenderInfo() because it can severely affect performance. No one said you had to. Render() merely requires that you write the output of those 2 lines. You can read from whatever pixels you need to.

*sigh* I guess it really is true that no new feature goes unpunished. There is no configuration. Nor will there be. Nor could there be. What you see is what 3.5 will be. If the fonts seem "thin" at smaller sizes, that's because Paint.NET is actually detecting that GDI had disabled antialiasing (for that font size) and so it's rendering in ClearType instead and applying a grayscale filter. Please TRUST ME. I tried EVERYTHING. I'm aware of EVERY deficiency, improvement, or difference from 3.36. I spent over two months on this. This is the best possible implementation. There will be no changes. If you want the best possible text, you will have to move to Vista or Win7. This is not a force-you-to-upgrade-your-OS conspiracy.

Yes, that's true (that a lot of people use XP). However, GDI+ isn't an option at all. It crashes a lot, which is unacceptable. Same with WPF's font stack. I spent a ton of time rewriting the font management and text rendering in 3.5. Beleive me when I say I did a thorough evaluation of the situation from all perspectives: rendering quality, correctness, reliability, performance, and demographics of the user base. XP users (a shrinking percentage btw) get stable and correct rendering now. Vista and Win7 users also get great rendering quality.

Wow, thanks. By the way, read the rules. Necroposting is rude. Thread Closed

"I need help" Sorry, but you also need to read the rules -- see #6 in particular. Thread Closed

What you're seeing is the difference between GDI+ and GDI. The former has been removed for reasons of reliability and performance. On Windows 7, Paint.NET will use DirectWrite which has much better text rendering.

Why are you replying to months old threads? Go read the rules. Thread Closed

Nope. Correct. Moving it now ...

You can't force them, no. But you can at least inform them that unless they upgrade (for free, no less) they won't get the full experience. See sites like http://www.ie6nomore.com/ It's not worth the effort to debug and optimize for pathologically old software or hardware. You have better things to do, even if it's drinking a beer and putting your feet up.

http://tinyurl.com/yjrpjtg

Try installing the 3.5 Beta 3. It may not fix it, but it will provide much more information in the crash log that could be helpful toward figuring this out.

The following ... (which is isomorphic to what you just posted) if (flag) { lock (sync) { if (flag) { // computation ... store/cache result flag = false; } } } use computation; ... is a standard pattern. Another variation that is subtly different is, lock (sync) { if (flag) { // computation ... store/cache result flag = false; } } use computation; The second one ensures that the computation is only ever performed once, and is required if the computation has any side effects (e.g., file accesses, etc.), or if reference identity is important (e.g. you are constructing a cache or dictionary or something). The first one allows most work items to complete without having to take a lock (assuming the # of work items is "larger enough" than the # of threads). However, when the work items first start out it's possible that the computation will be performed up to N times, where N is the # of threads being used. This results in higher CPU usage, but probably not an increase in "proper time" to complete execution (your stopwatch won't know any difference). Lower battery life is thus the real penalty there, but for this application it probably won't be an issue. The first pattern will probably give better performance in Paint.NET, since the first rendering slice is run -- by itself -- before the remaining slices*. Therefore only that first work item has to take a lock (a simple "lock(object){}" in .NET is cheap, although not free). However, I doubt you'll see any difference between the two since the total # of work items doesn't really get large until you have at least 8 threads. * This is not guaranteed to be true in the next version of Paint.NET. It is a performance optimization hint, not a correctness axiom.

It still has to wait for any remaining render code to stop. It doesn't throw them on the floor or do a Thread.Abort() (which would be disasterous).

Virus? Please take off your tinfoil hat.

That's happening because your plugin is taking an impossibly long time to do anything at all. I'm trying it on a 1000x336 picture right now and it's just gobbling up CPU time and producing no results. This is on a quad-core system. The bug is in your plugin -- it's just way too slow to be usable. After 2 minutes I had to kill it. (this is on a Core 2 Quad Q6600 2.4 GHz -- nothing extraordinary but hardly slow)

Why not use IndirectUI? For your plugins, since you just have a few simple integer properties, it would be much easier to create the UI. And it would then be consistent with the rest of the built-in effects.

Well that's to be expected ... normal minimum runtime will be O(W x H), but yours will be O((W x H)^2). I'm sure there's a numerical approximation, or at least a tricky but semantically equivalent optimization, for your filter that will greatly improve the runtime performance, but it may not be necessary given your needs.

You should install .NET 3.5 SP1. I'm not sure what it did to offend you, but I'm sure it's sorry.

It's probably not being reached because you're not doing any bounds checking. surface[x,y] will throw an exception if x,y is out of bounds. It should come back to you as an error dialog, but depending on how you're doing things this might not happen. For example, I don't know offhand how this gets reported when working in CodeLab.