Closed GoogleCodeExporter closed 9 years ago
Can you tell me the version and bitness of your Chrome? I want to make sure it
is
32-bit, because gdipp uses an assembly code snippet to inject gdimm, which is
supposed to work only for 32-bit Chrome.
I can start and render new tabs and close normally in my Windows 7 64-bit +
Chrome
5.0.342.3 32-bit. As far as I know, there is no official 64-bit release for
Chrome.
Original comment by crendk...@gmail.com
on 19 Mar 2010 at 6:09
4.1.249.1036 beta (41514)
I'm not very sure what bitness it is. Judging from windows task manager it
should be
32-bit
I might try 5.x beta later on
Original comment by ctb...@gmail.com
on 19 Mar 2010 at 10:13
Tried it on 5.0.356.0 beta, still having the same thing (could not close error)
Original comment by ctb...@gmail.com
on 20 Mar 2010 at 12:00
It happened to me once, but after I close Chrome and restart, the problem is
gone. I
still do not know how to stably reproduce the problem.
Original comment by crendk...@gmail.com
on 22 Mar 2010 at 10:59
[deleted comment]
I second the same error. And that error occurs only once.
But I can use chrome, after a second start, no problem.
I am using 0.7
Original comment by DCatcher...@gmail.com
on 23 Mar 2010 at 3:35
Now google chrome (5.0.356.2) crashes surely.
Original comment by DCatcher...@gmail.com
on 23 Mar 2010 at 7:15
I confirm that on chrome 5.0.356.2, with gdipp 0.7 service installation, it
still
produces the same error. After closing and restarting chrome it works fine.
However CPU usage is high with windows service method, wmiprese.exe is eating
up ~15%
of CPU constantly.
Registry method works fine as a whole. In previous gdipp versions I get
"Internet Low-
Mic utility has stopped working" (ielowutil.exe) error from time to time. None
so far
with 0.7 yet. Finger crossed :/
Original comment by ctb...@gmail.com
on 23 Mar 2010 at 1:38
Latest 0.7.1 x64 still crashes google chrome. It's really sad that chrome is
totally
unusable.
Original comment by DCatcher...@gmail.com
on 25 Mar 2010 at 1:53
Chrome still crashes on 0.7.1, but it's hardly unusable. Usually just crashes
for me
on first load after a reboot, SOMETIMES but not often again during the same
uptime.
Closing it and opening it again usually equals it working fine.
Original comment by audiobo...@gmail.com
on 25 Mar 2010 at 2:50
For the past few days I have been using 0.7.0 (the one that was pulled off)
with
registry setting, and everything works fine for me
Chrome starts normally, and no more ielowutil.exe error that I got before
Original comment by ctb...@gmail.com
on 25 Mar 2010 at 4:58
I am using chrome 5.0.356.2. After a clean install with no extension, chrome
stops
crashing.
As I guessed before, it may be the problem of addon system.
Original comment by DCatcher...@gmail.com
on 26 Mar 2010 at 3:07
Changed to registry mode with 0.7.1 and it's stopped crashing.
This is quite a buggy build, hopefully a new dev build today.
Original comment by audiobo...@gmail.com
on 26 Mar 2010 at 10:54
I am sorry to ask an off-topic question:
The most useful parameters of gdipp is text embolden and text shadow. Is the
function inherited from freetype or implemented in gdipp. I am using archlinux
and the text look too slim. Where can I find the parameters to tune text
weights
and shadow?
Original comment by DCatcher...@gmail.com
on 27 Mar 2010 at 12:33
Attachments:
Embolden is done by the FreeType function FT_Outline_Embolden
(http://freetype.sourceforge.net/freetype2/docs/reference/ft2-outline_processing
.html#FT_Outline_Embolden).
Shadow is implemented by gdipp. To embolden, apply the function on the glyph
outline
before rendering to bitmap. To make shadow, draw the bitmap with offset and
alpha first.
Original comment by crendk...@gmail.com
on 27 Mar 2010 at 10:30
Thanks for the enlightment!
Have you considered using existing cairo library to do high level graphic
rendering,
like text shadow. Direct2D backend for cairo is also in development.
Original comment by DCatcher...@gmail.com
on 28 Mar 2010 at 7:10
I considered Cairo before starting the project. However, I think directly
calling API
should outperform Cairo with respect of rendering performance. Besides, there
will be
more dependencies switching to Cairo.
Original comment by crendk...@gmail.com
on 29 Mar 2010 at 1:32
I have never had a problem with Chrome and gdimm when running with
"--no-sandbox".
Ideally of course the sandbox should work too, and I will occasionally try new
combinations of Chrome devel builds and gdimm but so far this is the most
stable way to
get it to work.
Original comment by greatq...@gmail.com
on 5 Apr 2010 at 9:08
Finally with 0.7.3, chrome stops crashing. The only problem is lagging when
using google reader and gmail.
All setting default.
Original comment by DCatcher...@gmail.com
on 7 Apr 2010 at 8:13
If you switch items very fast in Google Reader, it is indeed you can notice the
lag.
We are constantly optimizing the performance, however there is no free meal.
Good
glyphs come at a cost. Also, gdipp is user-space module. In order to access
kernel-space objects such as HDC, overhead is inevitable.
Original comment by crendk...@gmail.com
on 7 Apr 2010 at 12:12
Chrome has started crashing for me again on 0.7.4 :(
Can't use the registry method just now as it stops text appearing in LastFM. I
just
exclude it with services mode.
Original comment by audiobo...@gmail.com
on 12 Apr 2010 at 2:29
me too with 0.7.4
wired action with chrome, just exclude it.
Original comment by DCatcher...@gmail.com
on 12 Apr 2010 at 5:05
Original comment by crendk...@gmail.com
on 15 Apr 2010 at 10:51
With cache introduced in 0.7.5, lag in gmail and google reader is totally gone!
Wonderful work:)
Original comment by DCatcher...@gmail.com
on 17 Apr 2010 at 1:40
Nice to hear. You can further increase "cache_max_bytes" setting for larger
glyph
cache size.
Original comment by crendk...@gmail.com
on 17 Apr 2010 at 2:23
Nice advice~, I change the size to 20,000,000. Now everything is even smoother
and faster. However, I still
get the annoying error dialog when starting chrome after every restart of
windows... the old problem
though.
Original comment by DCatcher...@gmail.com
on 17 Apr 2010 at 4:36
Issue 46 has been merged into this issue.
Original comment by crendk...@gmail.com
on 22 Apr 2010 at 9:21
Issue 63 has been merged into this issue.
Original comment by crendk...@gmail.com
on 26 May 2010 at 5:19
this issue exist only at x64 system. on x86 work fine for me.
Original comment by Infecto...@gmail.com
on 5 Jun 2010 at 3:39
same problem using gdipp 0.8 and chrome 6.0.422.0
Original comment by netca...@gmail.com
on 6 Jun 2010 at 3:27
register method eliminates the problem. x64 with 0.8.1
Original comment by DCatcher...@gmail.com
on 19 Jun 2010 at 10:01
I'm using as service (0.8.1) and after a first error now it seems to work ..
Original comment by netca...@gmail.com
on 22 Jun 2010 at 1:28
Register method is the most stable!
Original comment by netca...@gmail.com
on 28 Jun 2010 at 8:47
Registry method does avoid the Chrome issue. What's the downside of using the
Registry method? What exactly are missing versus the Service method?
Original comment by shafqat....@gmail.com
on 29 Jun 2010 at 9:17
First, the registry method (writing the AppInit_DLLs value) is not recommended
by Microsoft. Although it is still available in Windows 7, it may be removed in
future versions. Second, the registry method is system-wide without
discrimination. This means critical system processes such as csrss.exe,
smss.exe are also injected the gdimm DLL, which potentially threatens system
stability. Third, you cannot cancel gdipp's render during system uptime. There
is no way to unload gdimm DLL from injected processes until their termination.
On the contrary, stopping service automatically unloads gdimm DLL from all
inject processes, since the injection mechanism is controlled by the service
itself.
If you find all these reasons trivial, registry method is good for you.
Original comment by crendk...@gmail.com
on 30 Jun 2010 at 4:46
what about this issue using 0.8.2 ?
Original comment by netca...@gmail.com
on 4 Jul 2010 at 11:57
Rendering is perfect in my case. I don't know if the csrss error message still
exists. At least I haven't encountered any.
Original comment by crendk...@gmail.com
on 4 Jul 2010 at 1:17
work fine now.
Original comment by Infecto...@gmail.com
on 4 Jul 2010 at 7:05
Original comment by crendk...@gmail.com
on 18 Sep 2010 at 5:31
same issue. can't load tabs in chrome after running gdipp services.
using:
vista x64.
chrome 12 stable version.
gdipp 0.91 beta.
chrome still load tabs but I can feel a big lag.
using: win7 x64
gdipp 0.91 beta.
Original comment by nghiangu...@gmail.com
on 10 Jun 2011 at 5:41
Original issue reported on code.google.com by
ctb...@gmail.com
on 19 Mar 2010 at 5:22