127424 - Remove unneccesary usage of glib calls in gfx/src/ code...

Status: RESOLVED WONTFIX

(Core :: XUL, enhancement, P5)

Description

[Roland Mainz]

RFE: Remove unneccesary usage of glib calls in gfx/src/ code...

Comment 1

[Roland Mainz]

Attachment: Patch for 2002-02-19-08-trunk

Comment 2

[tenthumbs]

Shouldn't that be fputs rather than puts? My man page says puts adds a 
newline of its own.

Comment 3

[Roland Mainz]

Attachment: Better patch for 2002-02-19-08-trunk per tenthumb's comment

Comment 4

[Daniel Brooks [:db48x]]

Comment on attachment 71091 [details] [diff] [review]
Better patch for 2002-02-19-08-trunk per tenthumb's comment

r=db48x

Comment 5

[Marc Attinasi]

Comment on attachment 71091 [details] [diff] [review]
Better patch for 2002-02-19-08-trunk per tenthumb's comment

sr=attinasi

Comment 6

[Christopher Blizzard (:blizzard)]

Please don't remove the glib code from the gtk rendering context code.  There's
no reason to do that and it just screws up cvs blame.

Comment 7

[Roland Mainz]

The code is AFAIK unneccesary. We call glib functions just for fun - or is there
any other reason ? blizzard ?

Comment 8

[Christopher Blizzard (:blizzard)]

and you replace it with equally fun code?

Comment 9

[Roland Mainz]

The code now uses XPCOM macros instead of the glib calls. The glib macros used
here have two disadvantages: They make use of g_log() (function call overhead)
and may be disabled if someone sets |G_DISABLE_CHECKS|.
Both is AFAIK not wanted.

blizzard:
Please explain why we need this "alien" code in the tree ? 
Why do you think that is MANDATORY that we have to use glib stuff instead of the
XPCOM macros here ?

Comment 10

[Christopher Blizzard (:blizzard)]

The code isn't "alien."  It's in the gtk code.  Also, the use of those functions
has been very helpful in the past at finding bugs.

Can you show me a _noticable_ performance improvement as a result of changing
that code?

Comment 11

[Roland Mainz]

Christopher Blizzard wrote:
> The code isn't "alien."  It's in the gtk code.  Also, the use of those 
> functions has been very helpful in the past at finding bugs.

Sure. I am not removing them, I only converted them to XPCOM. They are still
"there" and being usefull.

> Can you show me a _noticable_ performance improvement as a result of changing
> that code?

I did not do meansurements. I am trying to cleanup, that's all. The GTK+
functions cannot be used in Xlib code and I'd to keep both code lines in sync if
possible.

Comment 12

[Christopher Blizzard (:blizzard)]

> Sure. I am not removing them, I only converted them to XPCOM. They are still
> "there" and being usefull.

So you've traded one set of macros for another?  Plus, gtk will still log these
errors even in production code, assuming you have a gtk built with the g_log
functions enabled.  You're actually removing functionality from this code. 
Please don't.

>> Can you show me a _noticable_ performance improvement as a result of changing
>> that code?
> 
> I did not do meansurements. I am trying to cleanup, that's all. The GTK+
> functions cannot be used in Xlib code and I'd to keep both code lines in sync if
> possible.
> 

That's not enough reason to take this patch for me.

Comment 13

[Roland Mainz]

blizzard wrote:
> That's not enough reason to take this patch for me.

As you wish.

Comment 14

[Christopher Blizzard (:blizzard)]

You can still check in the changes to the Xlib code if you want.