alexo
-
Posts
72 -
Joined
-
Last visited
Content Type
Events
Profiles
Forums
Blogs
Gallery
Downloads
Posts posted by alexo
-
-
I'm not sure what caused the problem since I've never been able to reproduce the problem. There was something like a DivideByZeroException in the logs Rick sent me.
I have some changes that I've made and everything works fine on my machine, but then again, it was always working fine on my machine. Maybe I'll post an update later, but the same problem could just come up again for all I know.
The problem that I see is that PDN won't even let me load the plugin.
-
Where does the "This plugin is known to cause stability problems" message comes from anyway?
Can it be overridden? I never had stability problems with that plugin.
-
Downloaded the plugin pack.
PDN 3.5 says:
I'm aware of that and have no plans to fix them - only the plugins in the best pack are actively maintained. StockLibrary can be achieved by simply using a folder and SubtleEffect can be achieved by using a translucent layer. I'll still consider fixing and moving Flag, though.
Thank you Simon.
A small request though: would you be so kind as to tell me what DLLs you consider obsolete and recommend removing?
Thanks,
Alex.
-
You will need to give more info as to your Opp sys, PDN ver #, and pehaps a screen shot so the good folks here can help you,,,hehe I know from experience,,,I too am having problems,,and they know about some of them. The more info you can provide makes it more simple for the "repair men"
Joel b (aka kartracer)
OS: Win XP + SP3
PDN: Paint.NET v3.5 (Final Release build 3.50.3596.41598)
Screen shot: Of what? The errors are from "View plugin load errors".
I'll gladly provide more info, just tell me what.
-
File: C:\Program Files\Paint.NET\Effects\EOEffects.dll Effect Name: PaintDotNet.Effects.PDNOctagonal Full error message: This plugin is known to cause stability problems.Please help.
-
Downloaded the plugin pack.
PDN 3.5 says:
4 of 6 -------------- File: C:\Program Files\Paint.NET\Effects\Flags.dll Effect Name: Flags.EffectPlugin Full error message: This plugin is known to cause stability problems. 5 of 6 -------------- File: C:\Program Files\Paint.NET\Effects\StockLibrary.dll Effect Name: StockLibrary.EffectPlugin Full error message: This plugin is known to cause stability problems. 6 of 6 -------------- File: C:\Program Files\Paint.NET\Effects\SubtleEffect.dll Effect Name: EffectCaller.EffectPlugin Full error message: This plugin is incompatible with this version of Paint.NET.Please help.
-
Having errors loading the plugins:
1 of 6 -------------- File: C:\Program Files\Paint.NET\Effects\pyrochild.effects.common.dll Effect Name: PaintDotNet.UserControl2 Full error message: System.TypeLoadException: Could not load type 'PaintDotNet.UserControl2' from assembly 'PaintDotNet.Core, Version=3.50.3596.41599, Culture=neutral, PublicKeyToken=null'. 2 of 6 -------------- File: C:\Program Files\Paint.NET\Effects\pyrochild.effects.common.dll Effect Name: PaintDotNet.SurfaceBoxGraphicsRenderer Full error message: System.TypeLoadException: Could not load type 'PaintDotNet.SurfaceBoxGraphicsRenderer' from assembly 'PaintDotNet.Core, Version=3.50.3596.41599, Culture=neutral, PublicKeyToken=null'.Thanks,
Alex.
-
This happened to me with all the 3.5 betas and today with the final 3.5.
The installation of a new version tries to uninstall the existing one first.
When the uninstall progress bar reaches about 100%, the (un)installer hangs, using a lot of CPU but seemingly doing nothing.
Using the SysInternals ProcMon shows that the MSI process apparently tries to open each every registry key in existence.
Killing that process allows the installation to continue.
-
Correct. If you really want ClearType/FreeType rendering, I suggest a plug-in to do so.
That's an interesting idea but I was under the impression that plug-ins don't have the same access to the "rendering surface" (or however it is called) that the main program has. Or am I wrong?
-
Hi Illnab1024,
Rendering to subpixels is not advised at all for graphics processing -- it creates an image that when printed to a medium or scaled to a higher or lower resolution has those subpixel colors visible: i.e. it is only meant for LCD or CRT media which actually have subpixels.Thanks for the explanation.
So, if I understand you correctly, if one only works with images that are neither printed nor scaled up, there should not be any problem?
-
Hi Rick,
You have to trust me that I've chosen the best strategy given what was available. I never said there weren't trade-offs.Well, since I cannot convince you, I will accept your answer as final.
It is unfortunate that you no longer provide the source code though. I could have just "customized" it to my specific need without bugging you.
ClearType does not belong on bitmaps; it is only for rendering UI text.That is what I don't understand. You seem to feel strongly about it though, would you care to explain why is that the case?
Shipping is a feature too.Can't argue with that. Thanks again for providing us with a great application and good luck on the final release.
Best regards,
Alex.
-
Hi Rick,
*sigh* I guess it really is true that no new feature goes unpunished.Please don't get upset about this discussion. Nobody is suggesting that you're doing less than a terrific job with PDN.
Please hear me out. I don't bug you that often, do I? Give me 5 minutes of your attention and keep an open mind -- it's all I ask.
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.Bingo! Look at the image below:
The right side is ClearType as rendered by MS-Word 2003, the left side is PDN 3.5
As you can see in the zoom, the colors of CT are all over the map but, and it is a very important "but" for me, the actual small text (size 16) looks much better and I can't really see the colors at all -- it looks black unless you zoom it (the bottom part of the image is zoomed 600%)
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.My computer can't run Vista without a noticeable slowdown, so we're talking a hardware upgrade + the cost of an OS license.
Windows 7 is better than Vista but it costs even more *and* there is no upgrade path from XP so I cannot just transfer a hard drive over and upgrade, I'll have to install all the applications from scratch, mess up with settings for each, etc. Very disruptive in addition to expensive.
I'd rather pay you (or donate) a reasonable sum if making the grayscale filter optional will give me the same font rendering on XP as other applications have.
It cannot be more than 10 minutes of work for you and I'm willing to compensate you for it.
So, to summarize: I appreciate the time, effort and talent you poured into PDN, I don't doubt for a moment that you researched this extensively and arrived at an optimal solution, but i *BEG* you not to punish those that need a sub-optimal one.
Thank you for your time.
Best regards,
Alex.
-
What I noticed, Rick, is that the font antialiasing of 3.5b3 seems much more aggressive than that of 3.36.
It is mostly noticeable with thinner fonts in small to medium sizes. The effect is to make it seem that the strokes have "holes" in them.
That raises the question, how to you anti-alias fonts in PDN? Do you use CreateFontIndirect() with the lfQuality field of the LOGFONT set to ANTIALIASED_QUALITY (4)?
In that case, CLEARTYPE_QUALITY (5) or CLEARTYPE_NATURAL_QUALITY (6) may give different results. Could you make it user-configurable?
Thanks,
Alex.
-
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.
Rick, a lot of people run Paint.NET on XP and frankly, the fonts on 3.5beta look terrible in all but the largest of sizes. Performance may have increased but the image quality suffered greatly.
-
I mostly focused on #4, and I think it would be possible (but not easy) to turn the papers and source code into a working plug-in.
I'm more interested in the other three
I wonder if, due to Paint.NET being a showcase of Microsoft's .NET technology, the MS-Research people can be persuaded to contribute... Obviously I am not the person to approach them though.
-
There are some technologies from Microsoft Research that I'd love to see in Paint.NET (either natively or as plug-ins):
- [*:3vpyg5gh]
[*:3vpyg5gh]Patchworks for object removal.
[*:3vpyg5gh]Blender for seamless object insertion
[*:3vpyg5gh]Bayesian Color ConstancyIs it feasible?
-
If you must open an image that requires that much virtual memory allocation, then you must use a 64-bit version of Windows. Paint.NET does not use a paging system like that. It is not a bad idea, but would require a rewrite of substantial portions of the code. Hopefully someday, but definitely not anytime soon.
Sorry for being unclear Rick,
I was talking about opening multiple images simultaneously, where each one fits in available memory individually but the lot of them does not.
Thanks,
Alex.
-
Hi Rick,
Can you comment on my suggestion above?
Is is doable? Is is worth doing?
Thanks,
Alex.
-
I got an "insufficient memory" error when I tried opening a large number of images.
I understand that Paint.NET keeps the images in memory but there is actually a mechanism in Windows to allow an application to allocate huge amounts of virtual memory without the need of a 64-bit address space or the /3GB switch.
Raymond Chen explained how to to do it in 2004 in his blog (Myth: Without /3GB a single program can't allocate more than 2GB of virtual memory).
I will add that you are not even constrained by the size of your page file since CreateFileMapping can use a disk file for backing storage.
Now, I am not familiar enough with .NET to speculate on how easy it will be to implement such a technique, but if it is feasible (and I really hope that it is), the number of concurrently open images will only be constrained by free disk space (assuming any single image can fit in available memory). Obviously, the trade-off will be slower switching between images but it could be made a configuration option.
What do you think?
upgrading to 3.5 stuck on uninstall
in Troubleshooting & Bug Reports
Posted
Same thing happened when upgrading to 3.51.
Anyone?